Closed
Bug 1086960
Opened 10 years ago
Closed 9 years ago
[10.10] Sheets placed incorrectly on Yosemite
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
RESOLVED
FIXED
mozilla39
People
(Reporter: zpao, Assigned: mstange)
References
Details
Attachments
(1 file)
75.05 KB,
image/png
|
Details |
I know sheets have been awkward since Australis but I don't recall them being as bad as they currently look on Yosemite. They currently cut right across the tab strip and actually have a pixel of the tab label in them. Simple test case for Scratchpad - https://gist.github.com/zpao/a8825f0525bd272b6242 I think this might be a widget level problem but I'm too far gone to know where the theme/widget boundary really is these days.
Comment 1•10 years ago
|
||
The sheet in your screen shot is placed just below the "traditional" (22-pixel-high) titlebar. I'm not sure what we can do about it. It's true that Safari's Print sheet appears lower than that, and in an appropriate location. But unlike Safari we don't create our UI using native Cocoa objects. So for us to imitate Safari's behavior might require a lot of hacking.
Assignee | ||
Comment 2•10 years ago
|
||
We're using -[NSWindow setContentBorderThickness:forEdge:] to set the sheet position, see http://hg.mozilla.org/mozilla-central/annotate/fe1513fc09f6/widget/cocoa/nsCocoaWindow.mm#l3160 Maybe that's not the right way to do it on 10.10.
Updated•9 years ago
|
Summary: [10.10] sheet placement looks really bad → [10.10] Sheets placed incorrectly on Yosemite
Comment 3•9 years ago
|
||
Feel free to take this from me if you want it, Markus :-)
Assignee: nobody → smichaud
Assignee | ||
Comment 4•9 years ago
|
||
I have enough on my plate at the moment, so I'm happy to let you do it. :-) However, note that since bug 1052466 we no longer call setContentBorderThickness. You'll need to back out bug 1052466 locally for more efficient debugging. If we decide to keep bug 1052466 in the tree, I can do the work to make the vibrant titlebar behave like a toolbar again, but I'm going to ask UX to reconsider whether we want it first.
Assignee | ||
Comment 5•9 years ago
|
||
Looks like bug 1052466 really was the cause of this - the sheet position was tied to the toolbar geometry, and that bug made us stop using a toolbar. This bug has now been fixed by tying the sheet position to the tool*box* instead in bug 976722.
Assignee: smichaud → mstange
Status: NEW → RESOLVED
Closed: 9 years ago
Depends on: 976722
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in
before you can comment on or make changes to this bug.
Description
•