[Australis] When a window is in fullscreen mode and another window is opened in window mode, the title bar breaks

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
6 years ago
4 years ago

People

(Reporter: phlsa, Unassigned)

Tracking

(Blocks 1 bug)

28 Branch
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Australis:P4+])

Attachments

(2 attachments)

Steps to reproduce [Mac]:
- Open Nightly and send the window into fullscreen mode.
- Open a different window in normal (window) mode (e.g. by dragging a .html file to the Nightly dock icon)
- The title bar of the new window is broken (see attachment) and it also can't be dragged

In addition, after sending that new window into fullscreen mode and back, I got the appearance as in the second attachment. However, I can't reproduce this part reliably.

Comment 2

6 years ago
So this is because window.fullScreen lies, and so does the window's sizemode attribute - both claim the window's in fullscreen. Clicking the (+) button updates the sizemode attribute, but doesn't update the fullScreen property. I suspect this is a widget issue... Markus, any idea why this is and how we could fix it?
Flags: needinfo?(mstange)
Whiteboard: [Australis:P4]
Not yet, I'll take a look.
Whiteboard: [Australis:P4] → [Australis:P4+]
... or not. Xidorn, can you check whether this still reproduces?
Flags: needinfo?(mstange) → needinfo?(quanxunzhen)
Yes, with the STR in comment 0, I can reproduce this on Mac on Nightly. But the reason of this bug probably has been changed over time.

I have just worked out a simple fix for this bug on Nightly, which could fix the cause of this issue since bug 1173930 (so upliftable to aurora).

It seems to me that my fix indicates this bug was temporary be fixed in bug 1161802 unintentionally, but it seems it is also reproducible on 41... Not sure why, but my patch on hand definitely cannot be uplifted to that version.

This happens because
* we restore the window properties from XULStore, which in that case has sizemode=fullscreen [1]
* restoring that calls MakeFullScreen to enter fullscreen
* but we refuse to enter fullscreen because the window is not visible yet [2]

It is worth investigating whether we still need to workaround bug 752294. It seems to me at least on 10.10, calling toggleFullScreen before the window being visible works just fine. I'll push a try build for testing.

If we can remove that workaround, it seems this issue would be solved together as well.

[1] https://dxr.mozilla.org/mozilla-central/rev/d5cf4e7900df6b2351bf3677b49fb70bedf68b99/xpfe/appshell/nsXULWindow.cpp#1175
[2] https://dxr.mozilla.org/mozilla-central/rev/d5cf4e7900df6b2351bf3677b49fb70bedf68b99/widget/cocoa/nsCocoaWindow.mm#1456
Flags: needinfo?(quanxunzhen)
Wait... There is some related change in my local code of Nightly which I didn't noticed... which indicates that some of the result above might not be correct. But good news is that it seems to be fixable anyway.
smichaud, could you help test the try build in comment 7 and see whether bug 752294 still exists?
Flags: needinfo?(smichaud)
With this patch, you just undo my partial fix for bug 752294, and we once again see the bug I described in bug 752294 comment #1, bug 752294 comment #6 and bug 752294 comment #9.  So it's not acceptable on its own.

I tested on OS X 10.7.5.
Flags: needinfo?(smichaud)
It also doesn't fix this bug -- at least on OS X 10.7.5.
Yeah, if it doesn't fix bug 752294, then it won't fix this bug. So it means we probably still need to keep that special case.
Depends on: 1137009
This should have been fixed now?

Updated

4 years ago
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.