46 bytes, text/x-phabricator-request
|Details | Review|
HTML has the <progress> element, so we can potentially use that.
Non working WIP.
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
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
sorry, didn't notice this bug when filed bug 1491197
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1491197
I think we can leave this bug open to change consumers to use html:progress.
Setting needinfo for the review of PSM code, since it may disappear from dashboards otherwise.
(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.
With a trivial test fix: https://treeherder.mozilla.org/#/jobs?repo=try&revision=659e5a35a071c98bbfa0d7e96f764a9bc0fc548b
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.
Per discussion on IRC, it is fine for someone from the front-end team to rubberstamp this.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/6d6b5c10bba5 Use html:progress in front-end code. r=bgrins,Gijs
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.
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.
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!
You need to log in before you can comment on or make changes to this bug.