Remove unnecessary `-moz-binding: none` rules for richlistitems
Categories
(Toolkit :: Add-ons Manager, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox71 | --- | verified |
People
(Reporter: bgrins, Assigned: surkov)
References
Details
Attachments
(1 file)
This shouldn't be needed anymore since richlistitem is a Custom Element https://searchfox.org/mozilla-central/source/browser/components/preferences/handlers.css#5-7
|
Assignee | |
Comment 1•5 years ago
|
||
(In reply to Brian Grinstead [:bgrins] from comment #0)
This shouldn't be needed anymore since richlistitem is a Custom Element https://searchfox.org/mozilla-central/source/browser/components/preferences/handlers.css#5-7
Why not handle this and bug 1581591 same time in a single patch - the fix looks rather trivial? Do you worry about possible regressions?
|
|
Assignee | |
Comment 2•5 years ago
|
||
|
|
Assignee | |
Comment 3•5 years ago
|
||
(In reply to alexander :surkov (:asurkov) from comment #1)
(In reply to Brian Grinstead [:bgrins] from comment #0)
This shouldn't be needed anymore since richlistitem is a Custom Element https://searchfox.org/mozilla-central/source/browser/components/preferences/handlers.css#5-7
Why not handle this and bug 1581591 same time in a single patch - the fix looks rather trivial? Do you worry about possible regressions?
I pushed a patch that removes all moz-binding styles from richlistitems at once
|
|
Assignee | |
Comment 4•5 years ago
|
||
btw, there's a bunch of other elements with useless moz-binding style applied like tree, menubar and etc, which also should be removed
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 6•5 years ago
|
||
(In reply to alexander :surkov (:asurkov) from comment #1)
(In reply to Brian Grinstead [:bgrins] from comment #0)
This shouldn't be needed anymore since richlistitem is a Custom Element https://searchfox.org/mozilla-central/source/browser/components/preferences/handlers.css#5-7
Why not handle this and bug 1581591 same time in a single patch - the fix looks rather trivial? Do you worry about possible regressions?
Sure, makes sense to handle them all here.
(In reply to alexander :surkov (:asurkov) from comment #4)
btw, there's a bunch of other elements with useless moz-binding style applied like tree, menubar and etc, which also should be removed
Do you mind filing a new bug for that? We should go ahead and remove them now as well.
|
|
Reporter | |
Updated•5 years ago
|
Pushed by asurkov@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/19c786ed3d97 remove unnecessary moz-binding style from richlistitems r=bgrins
|
||
Comment 8•5 years ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 9•5 years ago
|
||
(In reply to Brian Grinstead [:bgrins] from comment #6)
Do you mind filing a new bug for that? We should go ahead and remove them now as well.
|
||
Comment 10•5 years ago
|
||
Hello,
Could this be tested manually by comparing certain pages from Firefox 71 against Firefox 70? If yes, could you please provide some examples/ steps to reproduce in order to correctly test this or otherwise set the "qe-verify-" flag.
Thank you
|
|
Assignee | |
Comment 11•5 years ago
|
||
(In reply to Miruna Curtean from comment #10)
Hello,
Could this be tested manually by comparing certain pages from Firefox 71 against Firefox 70? If yes, could you please provide some examples/ steps to reproduce in order to correctly test this or otherwise set the "qe-verify-" flag.
Thank you
richlistitems are almost everywhere, so you could check
- form autofills
- download manager
- preferences
for this bug, but I wouldn't expect regressions here, since the patch is rather straightforward.
|
||
Comment 12•5 years ago
|
||
Verified the fix using the latest Nightly (71.0a1/20190923215658) under Windows 10 Pro 64-bit and MacOS High Sierra 10.13.6.
To verify the issue I’ve checked the .css files mentioned above, including several other in their corresponding areas of the browser to search for the -moz-binding:none rule affecting richlistitems. This check has been performed in parallel with the latest Beta version (70.0b9/20190923154733) to check for differences in order to confirm the rule has been removed.
As such, I could not find references to the rule in the mentioned areas in the latest Nightly, confirming this fix.
Description
•