Open Bug 1299087 Opened 4 years ago Updated 2 years ago

Allow onbeforeunload dialog after interacting with flash

Categories

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

47 Branch
defect

Tracking

()

UNCONFIRMED

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
You need to log in before you can comment on or make changes to this bug.