Closed Bug 624391 Opened 14 years ago Closed 13 years ago

rendering issues when exiting Full Screen mode after a Firefox restart

Categories

(Firefox :: Session Restore, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 629860

People

(Reporter: AlexLakatos, Assigned: kael)

References

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110109 Firefox/4.0b9pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110109 Firefox/4.0b9pre

When exiting Full Screen mode after a Firefox restart, the window is not rendered, and if the mouse is moved the focused buttons from the window behind the Firefox window are rendered

Reproducible: Always

Steps to Reproduce:
1.Start Firefox with a clean profile
2.Go to https://addons.mozilla.org/en-US/firefox/?browse=featured
3.Install any supported add-on
4.Enter Full Screen mode
5.Click "Restart Now" in the door hanger notification
6.After restart is complete, exit Full Screen mode
Actual Results:  
6.The window is not rendered

Expected Results:  
6.The window exits Full Screen Mode
Version: unspecified → Trunk
Attached image screenshot
Status: UNCONFIRMED → NEW
Ever confirmed: true
maybe dup of Bug 618198
Pls ignore Comment #2, Bug 618198 is different bug because the regression range is different.


[STR]
1.Enter Full Screen F11 
2.Close by clicking "X"
3.Restart browser
4.Try to exit Full Screen F11
5. Mouse hover

This happens on WindowsXP Luna and Classic.
This happens on Windows7 AeroBasic and Classic.
This does not happen on Windows7 Aero.
This does not happen on Linux.

This problem happens *regardless* of the setting of hardware acceleration.

Actual Results:  
  The window does not repaint.
  Desktop and browser are messed up.
  Mouse hover on screen will render desctop icon and taskbar button.

Expected Results:  
  The window exits Full Screen Mode.

Regression window(cached hourly):
Works:
http://hg.mozilla.org/mozilla-central/rev/4edcf6c4cd03
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100831 Firefox/4.0b6pre ID:20100831101305
Fails:
http://hg.mozilla.org/mozilla-central/rev/6505b9f8aad0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100831 Firefox/4.0b6pre ID:20100831140952
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4edcf6c4cd03&tochange=6505b9f8aad0

In local build,
build from 6505b9f8aad0 : fails
build from b80f3d724eb3 : fails
build from ddbc06ca870f : fails
build from 9d7e7ac57f10 : fails
build from bfd87c4de2ff : works
build from ccf0c898b4c8 : works
build from 0d8d6369655d : works
build from 4edcf6c4cd03 : works

Regressed by:
9d7e7ac57f10	Rob Campbell — Bug 572038 - Create new Tree Panel for Inspector, r=gavin, a=blocking2.0
Blocks: 572038
blocking2.0: --- → ?
Keywords: regression
Hi Alice,

I'm still setting up my windows machine in classic to try this out, but you could test this with the devtools.inspector.enabled pref set to false in about:config and report back?
nevermind. I was able to reproduce it pretty easily. I'll take a closer look and see if I can figure out what caused it. Weird that this is only a Win Classic issue!
Whiteboard: [4b9]
Whiteboard: [4b9] → [4b9][session restore]
b9 has sailed. We won't get this until b10 at the earliest.
Whiteboard: [4b9][session restore] → [4b10][session restore]
One thing I've noticed while testing between Mac OS X and Win 7 is that full screen state isn't saved on restart in OS X. Might be a good idea to revert to a regular, maximized window on restart in Windows.
The inspector is default off. And it is not complete yet.
So, How about removing the code of the inspector from the browser?
I think we will if it comes to that. It's a lot of code though and fixing the underlying cause would be preferable.

Doing a little investigation still. I'm wondering if this is a result of an isActive flag not being set properly on the docshell when returning from session restore and setting the window to non full-screen?

see bug 594438 for another example of strange painting behavior.

CCing roc and JOEDREW for some additional speculation about what could be going wrong here.
Component: General → Session Restore
QA Contact: general → session.restore
Whiteboard: [4b10][session restore] → [4b10]
blocking2.0: ? → final+
Whiteboard: [4b10] → [4b10][softblocker]
Session Restore really doesn't handle the whole full screen mode thing. There is bug 539597 to start doing that though (but got held up on widget stuff which I never finished).
What part of the inspector patch caused this?
Assignee: nobody → kevin.gadd
I've attached before and after captures of Spy++'s information for our main window when reproducing this bug. The issue appears to be that when we restore our session at startup, we only restore the current position of the Firefox window - we don't restore the 'maximized' state, or the 'restore to' rectangle, so when we try to 'restore' the window out of Fullscreen, it has nowhere to go and ends up being restored to a random window rect and then set invisible (the WS_VISIBLE state is cleared). I'm not sure why this doesn't happen on Aero, or how the inspector changes could have caused it...
Attachment #512334 - Flags: review?(roc)
Ack, hit enter to dismiss an autocomplete menu and it submitted the attachment.

Anyway, this patch suppresses the behavior in RDF persistence of XUL windows that causes us to restore a window to fullscreen state (even though we can't do so correctly). With this patch applied, the window is restored in fullscreen state.

Unclear to me who would review for this.
Attachment #512334 - Attachment is obsolete: true
Attachment #512336 - Flags: review?
Attachment #512334 - Flags: review?(roc)
(In reply to comment #15)
> Anyway, this patch suppresses the behavior in RDF persistence of XUL windows
> that causes us to restore a window to fullscreen state (even though we can't do
> so correctly). With this patch applied, the window is restored in fullscreen
> state.

You mean *not* in fullscreen state?
Comment on attachment 512336 [details] [diff] [review]
Never restore a persisted XUL window to fullscreen state

Patch looks good to me, but let's try Neil.
Attachment #512336 - Flags: review? → review?(enndeakin)
Attachment #512336 - Flags: review?(enndeakin) → review+
(In reply to comment #17)
> Comment on attachment 512336 [details] [diff] [review]
> Never restore a persisted XUL window to fullscreen state
> 
> Patch looks good to me, but let's try Neil.

Wait! 
Bug 629860 seems something similar issue. 
I am not sure but Bug 629860 may be fix this too?
FYI
The problem by regression in comment #3 was fixed by the following range.
Broken:
http://hg.mozilla.org/mozilla-central/rev/49291ab908cc
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre ID:20100909175156
Fixed:
http://hg.mozilla.org/mozilla-central/rev/2aaeb42e51a6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre ID:20100909161351
Fixied Pushlog;
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=49291ab908cc&tochange=2aaeb42e51a6

And then new similar problem happens which described in Bug 629860.
(In reply to comment #16)
> (In reply to comment #15)
> > Anyway, this patch suppresses the behavior in RDF persistence of XUL windows
> > that causes us to restore a window to fullscreen state (even though we can't do
> > so correctly). With this patch applied, the window is restored in fullscreen
> > state.
> 
> You mean *not* in fullscreen state?

Yes, sorry - restored in regular maximized state instead of fullscreen.

The patch for Bug 629860 looks like it should fix this issue, since one of the symptoms is that the window is restored without visibility.
Depends on: 629860
(In reply to comment #14)
> Created attachment 512334 [details]
> Never restore a persisted XUL window to fullscreen state

I wouldn't mind preventing restore to full screen, it's a nightmare on windows. But we shouldn't restore to maximimzed, we should restore to the default window dimension. One of the bugs we fixed in 4.0 was a "restoring from fullscreen restores to a maximized window" bug, which wasn't desirable.
Do we want to always restore to regular windowed mode, then? Or just explicitly turn fullscreen into windowed mode instead of maximized?
(In reply to comment #22)
> Do we want to always restore to regular windowed mode, then? Or just explicitly
> turn fullscreen into windowed mode instead of maximized?

Just full screen imho. Maximized and minimized are fine. While things seem to be working ok now, code changes in widget can easily break things. (This is a call drivers / ux would probably need to make.)
Once you guys figure out what's happening here, feel free to ask for approval.
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110109
> Firefox/4.0b9pre
> Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110109
> Firefox/4.0b9pre
> 
> When exiting Full Screen mode after a Firefox restart, the window is not
> rendered, and if the mouse is moved the focused buttons from the window behind
> the Firefox window are rendered
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1.Start Firefox with a clean profile
> 2.Go to https://addons.mozilla.org/en-US/firefox/?browse=featured
> 3.Install any supported add-on
> 4.Enter Full Screen mode
> 5.Click "Restart Now" in the door hanger notification
> 6.After restart is complete, exit Full Screen mode
> Actual Results:  
> 6.The window is not rendered
> 
> Expected Results:  
> 6.The window exits Full Screen Mode

I think that the problem mentioned in comment#0 was fixed by Bug 629860.
So. this bug should be closed.
Status: NEW → RESOLVED
blocking2.0: final+ → ---
Closed: 13 years ago
Resolution: --- → DUPLICATE
Whiteboard: [4b10][softblocker]
For changing restore behavior on open, lets file a follow up if we think it's worth it.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: