Closed Bug 1581588 Opened 5 years ago Closed 5 years ago

Remove unnecessary `-moz-binding: none` rules for richlistitems

Categories

(Toolkit :: Add-ons Manager, task)

task
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla71
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

(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?

(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

btw, there's a bunch of other elements with useless moz-binding style applied like tree, menubar and etc, which also should be removed

Summary: Remove unnecessary `-moz-binding: none` rule in preferences/handlers.css → Remove unnecessary `-moz-binding: none` rules for richlistitems

(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.

Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Pushed by asurkov@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/19c786ed3d97 remove unnecessary moz-binding style from richlistitems r=bgrins
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

(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.

bug 1582227

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

Flags: needinfo?(surkov.alexander)

(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.
Flags: needinfo?(surkov.alexander)

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.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: