Closed
Bug 1186890
Opened 9 years ago
Closed 9 years ago
[e10s] Navigation doesn't exit fullscreen correctly
Categories
(Core :: DOM: Events, defect)
Core
DOM: Events
Tracking
()
RESOLVED
FIXED
mozilla42
People
(Reporter: vtamas, Assigned: xidorn)
References
Details
Attachments
(1 file)
1.28 KB,
patch
|
Dolske
:
review+
|
Details | Diff | Splinter Review |
Reproducible on: Firefox 42.0a1 with e10s enabled across all platforms STR 1. Start Firefox. 2. Open a PDF file (e.g. http://cp.literature.agilent.com/litweb/pdf/5989-8139EN.pdf ) 3. Click the "Presentation Mode" button to enter in full screen mode. 4. Right click to open the context menu. 5. Click on “Reload current page” button. ER The Presentation mode is cancelled when a PDF document is refreshed in fullscreen mode in a non-e10s window. AR - The PDF document remains in presentation mode - The background colour changes in gray - The pdf toolbar is displayed Additional notes: - This issue is reproducible on Firefox 42.0a1 (2015-07-22) under Windows 8.1 32-bit, Mac OS X 10.10.4 and Ubuntu 13.10 64-bit. - This issue is e10s specific. Regression window: (m-c) Last good revision: c6bbf8f1b02b (2015-05-26) First bad revision: ff2e07228041 (2015-05-27) Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c6bbf8f1b02b&tocha nge=ff2e07228041
Updated•9 years ago
|
Flags: needinfo?(quanxunzhen)
Assignee | ||
Comment 1•9 years ago
|
||
It is expected to fully exit fullscreen when navigation happens, which includes refreshing. This is a Core bug, not a Firefox one.
Component: PDF Viewer → DOM: Events
Flags: needinfo?(quanxunzhen)
Product: Firefox → Core
Summary: [e10s] Strange behaviour while refreshing the PDF in presentation mode → [e10s] Navigation doesn't exit fullscreen correctly
Version: 42 Branch → Trunk
Assignee | ||
Updated•9 years ago
|
tracking-e10s:
--- → ?
Assignee | ||
Updated•9 years ago
|
status-firefox41:
--- → affected
Assignee | ||
Comment 2•9 years ago
|
||
TBH, I don't know how everything even works before this regression... But this patch should be useful anyway.
Assignee: nobody → quanxunzhen
Attachment #8639220 -
Flags: review?(dao)
Updated•9 years ago
|
Assignee | ||
Comment 3•9 years ago
|
||
Ping :dao. Did you somehow ignore the patch here?
Flags: needinfo?(dao)
Comment 5•9 years ago
|
||
Comment on attachment 8639220 [details] [diff] [review] patch Review of attachment 8639220 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/base/content/tab-content.js @@ +650,5 @@ > + // If we receive any fullscreen change event, and find we are > + // actually not in fullscreen, also ask the parent to exit to > + // ensure that the parent always exits fullscreen when we do. > + sendAsyncMessage("DOMFullscreen:Exit"); > + } Hmm, so, what's actually happening when reproducing this? Presumably we're not _entering_ fullscreen. And so I'd have expected MozDOMFullscreen:Exit to fire before the :Exited, where we should have done the same sendAsyncMessage(). So is that event not firing? Or is its sendAsyncMessage() not actually exiting fullscreen? Seems like a proper fix would be to address whichever of those is happening, instead of just bandaiding over that bug?
Updated•9 years ago
|
Flags: needinfo?(quanxunzhen)
Assignee | ||
Comment 6•9 years ago
|
||
(In reply to Justin Dolske [:Dolske] from comment #5) > Comment on attachment 8639220 [details] [diff] [review] > patch > > Review of attachment 8639220 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: browser/base/content/tab-content.js > @@ +650,5 @@ > > + // If we receive any fullscreen change event, and find we are > > + // actually not in fullscreen, also ask the parent to exit to > > + // ensure that the parent always exits fullscreen when we do. > > + sendAsyncMessage("DOMFullscreen:Exit"); > > + } > > Hmm, so, what's actually happening when reproducing this? Nothing happens. The parent process isn't aware that the content process has exited fullscreen. > Presumably we're not _entering_ fullscreen. And so I'd have expected > MozDOMFullscreen:Exit to fire before the :Exited, where we should have done > the same sendAsyncMessage(). MozDOMFullscreen:Exit is designed to be fired if the page itself asks to exit fullscreen. Probably a name like :RequestExit would be better for that event. When the content accidentally exit fullscreen state because of navigation or fullscreen element removal, the parent process won't be notified. It seems I ignored these situations when I change the whole logic, and that's why I said I don't understand how everything worked before the regression. > So is that event not firing? Or is its sendAsyncMessage() not actually > exiting fullscreen? Seems like a proper fix would be to address whichever of > those is happening, instead of just bandaiding over that bug? No, that event is not designed to fire at this case. When the fullscreen change has happened, only :Exited should fire.
Flags: needinfo?(quanxunzhen)
Comment 7•9 years ago
|
||
(In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #6) > > Presumably we're not _entering_ fullscreen. And so I'd have expected > > MozDOMFullscreen:Exit to fire before the :Exited, where we should have done > > the same sendAsyncMessage(). > > MozDOMFullscreen:Exit is designed to be fired if the page itself asks to > exit fullscreen. Probably a name like :RequestExit would be better for that > event. Ah, indeed. That's confusing. Can you maybe just go ahead and rename that? (These events are all chrome-only, right?) In fact, is there even a reason to have two different Exit/Exited events? Why not just have a single, common event? Finally, I'll note that it would be most helpful to have a 1-2 line comment for each case in receiveMessage / handleEvent explaining what each is for. Ditto for the related code in browser-fullScreen.js. It's hard to understand each, as well as the overall control flow. > that's why I > said I don't understand how everything worked before the regression. Would be worth understanding how this worked before! Maybe we're missing something else. Oh, and a test would be great here.
Assignee | ||
Comment 8•9 years ago
|
||
(In reply to Justin Dolske [:Dolske] from comment #7) > Ah, indeed. That's confusing. Can you maybe just go ahead and rename that? > (These events are all chrome-only, right?) Yes, they are all chrome-only. I'll try to rename them. > In fact, is there even a reason to have two different Exit/Exited events? > Why not just have a single, common event? Becasue we want to change the window size before toggling the document state, so that we can: 1. have the transition for fullscreen change, 2. have a stable viewport size when we notify the content we finish the fullscreen change
Comment 9•9 years ago
|
||
Comment on attachment 8639220 [details] [diff] [review] patch Seems like dolske dived into this and is prepared to finish the review. If I misunderstood and those were just drive-by comments, feel free to redirect the request to me. FWIW, I had the same feeling that this is a band-aid and that a "proper" fix might be more appropriate.
Flags: needinfo?(dao)
Attachment #8639220 -
Flags: review?(dao) → review?(dolske)
Assignee | ||
Comment 10•9 years ago
|
||
(In reply to Justin Dolske [:Dolske] from comment #7) > Oh, and a test would be great here. I believe we have had tests for this... just disabled on e10s... I'll try to enable Fullscreen API tests on e10s later in bug 1191597.
Assignee | ||
Comment 11•9 years ago
|
||
(In reply to Justin Dolske [:Dolske] from comment #7) > > that's why I > > said I don't understand how everything worked before the regression. > > Would be worth understanding how this worked before! Maybe we're missing > something else. OK, it is probably not a regression at all. I tested the Nightly on 2015-05-25 (the day before "Last good revision" in comment 0), but navigation doesn't exit fullscreen either. The reporter thought it worked probably because the PDF viewer started using a different approach at that day. This bug exists far before that.
Assignee | ||
Comment 12•9 years ago
|
||
Probably I should create a wiki page to describe the whole flow.
Assignee | ||
Comment 13•9 years ago
|
||
I've created a wiki page to briefly describe the basic control flow of fullscreen stuffs: https://wiki.mozilla.org/Gecko:Fullscreen_API . Hopefully it could make things easier to understand. The section E10S / Exiting Fullscreen Unexpectedly describes the steps I proposed in the patch here. Based on this, Dolske, could you continue review this patch?
Flags: needinfo?(dolske)
Updated•9 years ago
|
Attachment #8639220 -
Flags: review?(dolske) → review+
Comment 14•9 years ago
|
||
(In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #13) > I've created a wiki page to briefly describe the basic control flow of > fullscreen stuffs: https://wiki.mozilla.org/Gecko:Fullscreen_API . Hopefully > it could make things easier to understand. Thanks for documenting this and explaining here. Makes a lot more sense to me.
Flags: needinfo?(dolske)
Assignee | ||
Comment 15•9 years ago
|
||
url: https://hg.mozilla.org/integration/mozilla-inbound/rev/dee3e26cc1c0f4deeb49eaa06b03a3c06ac4927f changeset: dee3e26cc1c0f4deeb49eaa06b03a3c06ac4927f user: Xidorn Quan <quanxunzhen@gmail.com> date: Fri Aug 07 13:38:10 2015 +1000 description: Bug 1186890 - Ensure parent always know when the child exit fullscreen. r=Dolske
Assignee | ||
Comment 16•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/dee3e26cc1c0
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in
before you can comment on or make changes to this bug.
Description
•