Closed Bug 1393411 Opened 3 years ago Closed 3 years ago

Bookmarks and History subviews are cut off

Categories

(Firefox :: Theme, defect, P1)

57 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 57
Iteration:
57.2 - Aug 29
Tracking Status
firefox57 --- verified

People

(Reporter: Ovidiu, Assigned: Gijs)

References

(Blocks 1 open bug)

Details

(Whiteboard: [reserve-photon-structure])

Attachments

(2 files)

[Affected versions]:

Nightly 57.0a1(2017-08-24)

[Affected platforms]:

Tested on Mac OS X 10.10 and Mac Os X 10.12, on other OSes the latest Nightly didn't land. I will update this bug after I test on the latest Nightly.

[Steps to reproduce]:

 Click on Menu -> library -> Bookmarks or History

[Actual result]:

The bookmarks are cut off.

[Expected result]:

The bookmarks are displayed correctly. 

Please see the attachment 

Note: This is a regression, on the Nightly from 2017-08-23 I can't reproduce this. I tried to use mozregression but I have some issues and I can't get a regression window.
Blocks: photon-structure
No longer blocks: photon-visual
Summary: Bookmarks and History dialog is cut off → Bookmarks and History subviews are cut off
Whiteboard: [photon-structure][triage]
Hmm, this could be a regression from bug 1391017 which moved toolbarbutton.bookmark-item { max-width: 13em; } from being directly in browser.css to a different place in toolbarbuttons.inc.css, so I guess it could take precedence over some other rule that ends up before this in browser.css.
Or maybe it's :not(#bookmarks-toolbar-placeholder) that boosts this rule's specificity.
I can reproduce, but not a lot of stuff landed inbetween these 2 nightlies, so I'm puzzled as to what would have caused this... trying mozregression myself right now. Already tested turning stylo on/off, made no difference.
(In reply to Dão Gottwald [::dao] from comment #1)
> Hmm, this could be a regression from bug 1391017 which moved
> toolbarbutton.bookmark-item { max-width: 13em; } from being directly in
> browser.css to a different place in toolbarbuttons.inc.css, so I guess it
> could take precedence over some other rule that ends up before this in
> browser.css.

Ah, this would be plausible. I'll see if I can confirm with mozregression.
Yep, https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6ccd5cf829e2af1d068d2ac87e80bfe0687f9136&tochange=b45c8f18e2463f0f20130236e86aeb8f51b82b12 .

Testing with the style editor, reducing the specificity by removing the :not(...) fixes this.
Blocks: 1391017
Patch incoming. Not really sure if max-width: none is more or less appropriate than unset, let me know if you feel strongly.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Priority: -- → P1
Iteration: --- → 57.2 - Aug 29
Flags: qe-verify+
QA Contact: ovidiu.boca
Whiteboard: [photon-structure][triage] → [reserve-photon-structure]
Comment on attachment 8900696 [details]
Bug 1393411 - avoid setting the max-width of bookmark items with too great a specificity,

https://reviewboard.mozilla.org/r/172142/#review177406
Attachment #8900696 - Flags: review?(dao+bmo) → review+
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/109578ac95f6
avoid setting the max-width of bookmark items with too great a specificity, r=dao
Duplicate of this bug: 1393527
Duplicate of this bug: 1393541
https://hg.mozilla.org/mozilla-central/rev/109578ac95f6
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
I verified this on Mac OS X 10.10, Windows 10 x64 with Nightly 57.0a1(2017-08-25) and I can confirm the fix.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Duplicate of this bug: 1393794
You need to log in before you can comment on or make changes to this bug.