Closed
Bug 1428869
Opened 7 years ago
Closed 6 years ago
Change progressmeter to be html:progress
Categories
(Toolkit :: UI Widgets, task, P5)
Toolkit
UI Widgets
Tracking
()
VERIFIED
FIXED
mozilla64
People
(Reporter: ntim, Assigned: Paolo)
References
Details
Attachments
(1 file, 1 obsolete file)
HTML has the <progress> element, so we can potentially use that.
Reporter | ||
Comment 1•7 years ago
|
||
Non working WIP.
Reporter | ||
Comment 2•7 years ago
|
||
After playing with it, I don't think this worth the effort. It doesn't remove an enormous amount of code, and requires to a lot of effort to fix the tests and the styling. However, we can potentially change `progressmeter` in the future to be a custom element, or simply change everything to a HTML <progress> element: * <progressmeter mode="undeterminate"> corresponds to an HTML <progress> with no value. * the value attribute corresponds to the HTML <progress> value attribute * the max attribute is also the same as its HTML counterpart
Reporter | ||
Updated•7 years ago
|
Assignee: ntim.bugs → nobody
Comment 3•7 years ago
|
||
Updated the bug title to match Comment 2
Summary: Investigate simplifying progressmeter.xml binding → Convert progressmeter bindings to Custom Elements, or change consumers to use html:progress directly
Updated•7 years ago
|
Priority: -- → P5
Comment 4•6 years ago
|
||
sorry, didn't notice this bug when filed bug 1491197
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 5•6 years ago
|
||
I think we can leave this bug open to change consumers to use html:progress.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Convert progressmeter bindings to Custom Elements, or change consumers to use html:progress directly → Change progressmeter to be html:progress
Assignee | ||
Updated•6 years ago
|
Blocks: war-on-xbl
Assignee | ||
Comment 6•6 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Attachment #8940836 -
Attachment is obsolete: true
Assignee | ||
Updated•6 years ago
|
Flags: qe-verify+
Assignee | ||
Comment 7•6 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=68d02cc5b13178c59a406b359fdb5a6ef473eb72
Assignee | ||
Comment 8•6 years ago
|
||
Setting needinfo for the review of PSM code, since it may disappear from dashboards otherwise.
Flags: needinfo?(honzab.moz)
Comment 9•6 years ago
|
||
(In reply to :Paolo Amadini from comment #8) > Setting needinfo for the review of PSM code, since it may disappear from > dashboards otherwise. Yeah, I don't see it my phab.
Assignee | ||
Comment 10•6 years ago
|
||
With a trivial test fix: https://treeherder.mozilla.org/#/jobs?repo=try&revision=659e5a35a071c98bbfa0d7e96f764a9bc0fc548b
Comment 11•6 years ago
|
||
Paolo, I'm not sure why I should review UI changes. I don't know those parts at all, despite I'm still a PSM peer. So I don't think I can review your changes well.
Flags: needinfo?(honzab.moz)
Assignee | ||
Comment 12•6 years ago
|
||
Per discussion on IRC, it is fine for someone from the front-end team to rubberstamp this.
Comment 13•6 years ago
|
||
Pushed by paolo.mozmail@amadzone.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/6d6b5c10bba5 Use html:progress in front-end code. r=bgrins,Gijs
Reporter | ||
Updated•6 years ago
|
Assignee: nobody → paolo.mozmail
Comment 14•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6d6b5c10bba5
Status: REOPENED → RESOLVED
Closed: 6 years ago → 6 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Comment 15•6 years ago
|
||
Sorry for the lack of knowledge on this matter. I have to ask you to provide some sort of STR that I could use to verify your bug. Thank you.
Flags: needinfo?(paolo.mozmail)
Assignee | ||
Comment 16•6 years ago
|
||
This bug changed the internal implementation of the progress bar for the following cases: - Updating the application, not in the background but through the separate window - Setting or changing the Master Password, for the password strength indication - Using the Reset Firefox feature - Installing an add-on The cases above are the primary ones, we need to verify that the progress bar is still working. There's also a WebIDE change that we don't need to test specifically, and some less used cases: - Setting a password for the Software Security Device in the Security Devices preferences - Setting a password when backing up a personal certificate Checking the latter cases is less important that the first four, since they are more rarely used and steps to reproduce may be more complex, for example they may require generating a personal certificate.
Flags: needinfo?(paolo.mozmail)
Comment 17•6 years ago
|
||
I have verified the functionality and UI of the following cases on Nightly v65.0a1 from 2018-10-23: - Updating the application, not in the background but through the separate window - Setting or changing the Master Password, for the password strength indication - Using the Reset Firefox feature - Installing an add-on No issues stood out while performing these actions multiple times and the progress bar's UI performed as before. I don't know how to create a personal certificate, so I have skipped testing that part. If you think this is a mandatory test, please provide me with a link/tutorial on how I can create a personal certificate and I will do it. Thank you!
Status: RESOLVED → VERIFIED
status-firefox64:
fixed → ---
status-firefox65:
--- → verified
Flags: qe-verify+
Updated•6 years ago
|
status-firefox64:
--- → verified
Reporter | ||
Updated•5 years ago
|
Type: enhancement → task
You need to log in
before you can comment on or make changes to this bug.
Description
•