Change progressmeter to be html:progress

VERIFIED FIXED in Firefox 64

Status

()

task
P5
normal
VERIFIED FIXED
2 years ago
20 days ago

People

(Reporter: ntim, Assigned: Paolo)

Tracking

(Blocks 1 bug)

unspecified
mozilla64
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 verified, firefox65 verified)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

2 years ago
HTML has the <progress> element, so we can potentially use that.
Reporter

Comment 1

2 years ago
Posted patch wip-progressmeter.patch (obsolete) — Splinter Review
Non working WIP.
Reporter

Comment 2

2 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

2 years ago
Assignee: ntim.bugs → nobody
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

Last year
Priority: -- → P5
sorry, didn't notice this bug when filed bug 1491197
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1491197
Reporter

Comment 5

9 months ago
I think we can leave this bug open to change consumers to use html:progress.
Blocks: 1491197
No longer blocks: war-on-xbl
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

9 months ago
Blocks: war-on-xbl
Assignee

Updated

8 months ago
Depends on: 1499704
Reporter

Updated

8 months ago
Depends on: 1498140
Assignee

Updated

8 months ago
Attachment #8940836 - Attachment is obsolete: true
Assignee

Updated

8 months ago
Flags: qe-verify+
Blocks: 1499843
No longer blocks: 1499843
Assignee

Comment 8

8 months ago
Setting needinfo for the review of PSM code, since it may disappear from dashboards otherwise.
Flags: needinfo?(honzab.moz)
(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.
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

8 months ago
Per discussion on IRC, it is fine for someone from the front-end team to rubberstamp this.

Comment 13

8 months 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

8 months ago
Assignee: nobody → paolo.mozmail

Comment 14

8 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/6d6b5c10bba5
Status: REOPENED → RESOLVED
Closed: 9 months ago8 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
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

8 months 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)
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
Flags: qe-verify+
Assignee

Updated

7 months ago
Depends on: 1507829
Reporter

Updated

20 days ago
Type: enhancement → task
You need to log in before you can comment on or make changes to this bug.