Closed Bug 1299087 Opened 8 years ago Closed 3 years ago

Allow onbeforeunload dialog after interacting with flash

Categories

(Core :: DOM: Core & HTML, defect, P5)

47 Branch
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: dennis.hannwacker, Unassigned)

Details

Attachments

(3 files)

4.94 KB, text/html
Details
621.12 KB, application/x-shockwave-flash
Details
164 bytes, application/x-javascript
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160623154057 Steps to reproduce: Listening for onbeforeunload event to show dialog to check back with user, if he really wants to leave site. Such showing of a dialog before leaving the site was restricted in Bug 636905 to be only allowed after user interaced with the page (mouse-/keyboard-events in the browser window). The problem is that interactions with a flash application are not registered towards this check and do not count as such interactions. So in case of a fullscreen flash application clicks on ui-elements (buttons, lists, trees) inside this flash application are not recognized as interactions with the site in terms of Bug 636905. Only mouse-wheel in/over the flash-application seems to trigger the setting of the introduced flag "userHasInteracted". Actual results: After user opened site with flash application, then interacted with it and then closed browser tab, the dialog opened from within the onbeforeunload-handler was not shown. Expected results: After user opened site with flash application, then interacted with it and then closed browser tab, the dialog opened from within the onbeforeunload-handler should be shown.
Component: Untriaged → DOM
Product: Firefox → Core
Hi Gijs, what do you think? Thanks!
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #1) > Hi Gijs, what do you think? Thanks! It's not clear from the question "what do you think?" what you expect from me. If it helps: I don't have time to investigate this further. I'm not part of the DOM team so I don't know how it should be prioritized otherwise. In future, please ask a more specific question. I mean, this might be a real bug. I don't know much about flash. Does this happen to just any flash app, or only this particular one? A testcase would really help! Does this also happen when wmode=transparent? Etc. In case you're asking me purely because I wrote the patch in 636905: I don't think it's severe enough to back out bug 636905 over. The direction our integration of flash and beforeunload has gone in mean that I think it doesn't need to be prioritized over other things I'm (and/or other people are) working on. I have no idea if that answers your question or not.
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(htsai)
> Does this also happen when wmode=transparent? That is an excellent point. I made some tests and the problem can only be observed with wmode=direct. So wmode=transparent and wmode=opaque seem to work fine.
Attached file Test.html
Html file for test case. Uses following test.swf and test.js
Attached file Test.swf
Swf (flash-file) for test case. Used by test.html
Attached file test.js
Javascript file (registering onberforeclose handler) for test case. Used by test.html.
(In reply to :Gijs Kruitbosch from comment #2) > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #1) > > Hi Gijs, what do you think? Thanks! > > It's not clear from the question "what do you think?" what you expect from > me. If it helps: I don't have time to investigate this further. I'm not part > of the DOM team so I don't know how it should be prioritized otherwise. In > future, please ask a more specific question. > My bad, I should have asked a more specific question. Thanks for the reply. :) > I mean, this might be a real bug. > I don't know much about flash. Does this happen to just any flash app, or only this particular one? > A testcase would really help! Does this also happen when wmode=transparent? Etc. They are great points. > In case you're asking me purely because I wrote the patch in 636905: I don't > think it's severe enough to back out bug 636905 over. I see, thanks. > The direction our integration of flash and beforeunload has gone in mean that I think it > doesn't need to be prioritized over other things I'm (and/or other people > are) working on. I have no idea if that answers your question or not. Yes, you answered my question well. Thank you so much for the comment. :)
Flags: needinfo?(htsai)
Benjamin, do you think this needs to be prioritized above P5?
Flags: needinfo?(benjamin)
Priority: -- → P5
Nope. It might already work with windowless Flash (wmode=opaque), which would be a fine workaround and will soon be the default. But Flash isn't the web, and I'm fine with fullpage Flash apps not being able to use beforeunload.
Flags: needinfo?(benjamin)
(In reply to Benjamin Smedberg [:bsmedberg] from comment #9) > Nope. It might already work with windowless Flash (wmode=opaque), which > would be a fine workaround and will soon be the default. The problem is for any application/site using Stage 3D (like for example 3D-Games or other embedded 3D-Content), wmode "opaque" is not an option. One has to use mode "direct" to have access to Stage 3D (Context3D). And in wmode "direct" the described problem can be observed.
Component: DOM → DOM: Core & HTML

Flash is no longer supported

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

Attachment

General

Created:
Updated:
Size: