Closed Bug 1506342 Opened 6 years ago Closed 6 years ago

Ctrl+Tab preview styling is broken

Categories

(Firefox :: Theme, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 65
Tracking Status
firefox-esr60 --- unaffected
firefox63 --- unaffected
firefox64 --- unaffected
firefox65 --- verified
firefox66 --- verified

People

(Reporter: dao, Assigned: dao)

References

Details

(Keywords: regression)

Attachments

(1 file)

There's this hack where we make Ctrl+Tab previews use the button-base binding instead of the standard button one in order to skip button.css. Now that button.css is loaded as a document stylesheet, this stopped working.
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/06a2943bfa3f
Fix Ctrl+Tab preview styling. r=bgrins
https://hg.mozilla.org/mozilla-central/rev/06a2943bfa3f
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 65
Thanks for removing this special binding! As noted in bug 1450823, when converting "button" to Custom Element, we'll probably need a subclass like <button is="button-plain"> that doesn't create any anonymous content. As I understand it, we have this behavior here because, in XBL, children that don't match any "children" element override the entire <content>.
(In reply to :Paolo Amadini from comment #5)
> Thanks for removing this special binding! As noted in bug 1450823, when
> converting "button" to Custom Element, we'll probably need a subclass like
> <button is="button-plain"> that doesn't create any anonymous content. As I
> understand it, we have this behavior here because, in XBL, children that
> don't match any "children" element override the entire <content>.

Can't the custom element check if there are child nodes and not create the anonymous content in that case?
Flags: needinfo?(paolo.mozmail)
Depends on: 1506810
See Also: → 1506810
If we end up using a delayed connected callback for "button" then that would be possible, otherwise if I remember correctly we don't have access to children when the element is connected during parsing, even if they are defined. Also, just checking whether there are children may slow down the creation, and if it's only one or two consumers who need this, it's probably more performant to have a separate subclass.

Brian would probably know more, anyways we don't have to worry about this until we tackle the button binding.
Flags: needinfo?(paolo.mozmail)
No longer depends on: 1506810
See Also: → 1511208
Flags: qe-verify+

I successfully reproduced the issue on Firefox Nightly 65.0a1 (2018-11-10) under Windows 10 (x64).

The issue is no longer reproducible under Firefox Beta 65.0b12 and latest Nightly 66.0a1 (2019-01-20). Tests were performed under Windows 10 (x64), macOS 10.12 and Ubuntu 16.04 (x64).

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

Attachment

General

Created:
Updated:
Size: