1396448 - window.Notification.requestPermission() firefox hang

Status: RESOLVED DUPLICATE of bug 1372085

(Firefox :: Site Identity, defect, P2)

Description

[hef]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053838

Steps to reproduce:

in javascript:

    while(true) {
        window.Notification.requestPermission();
    }

Will cause firefox to lock up and become unresponsive.  Best of all, restarting firefox reloads the page containing the javascript and firefox.

I created a repro here: https://hef.github.io/freeze-on-notification-repro/
Be warned, that triggers the bug on page load.  You might have to set a response allowing popups.  I hit "allow", I'm not sure what happens if you say "not now" or "never"



Actual results:

Firefox locks up and becomes unresponsive.


Expected results:

Ideally, firefox would not lock up and eventually prompt the user about an unresponsive script.

Comment 1

[Panos Astithas (he/him) [:past] (please ni?)]

Setting sec-private, but I'm not sure if dos-type bugs need to be.

It's pretty bad when sites can DOS us, but I don't expect this to be too hard to fix. Wennie, is there someone who can look into this?

Comment 2

[(inactive) Nihanth Subramanya [:nhnt11]]

(In reply to hef from comment #0)
> User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0)
> Gecko/20100101 Firefox/55.0
> Build ID: 20170824053838
> 
> Steps to reproduce:
> 
> in javascript:
> 
>     while(true) {
>         window.Notification.requestPermission();
>     }
> 
> Will cause firefox to lock up and become unresponsive.  Best of all,
> restarting firefox reloads the page containing the javascript and firefox.
> 
> I created a repro here: https://hef.github.io/freeze-on-notification-repro/
> Be warned, that triggers the bug on page load.  You might have to set a
> response allowing popups.  I hit "allow", I'm not sure what happens if you
> say "not now" or "never"
> 
> 
> 
> Actual results:
> 
> Firefox locks up and becomes unresponsive.
> 
> 
> Expected results:
> 
> Ideally, firefox would not lock up and eventually prompt the user about an
> unresponsive script.

I attempted to reproduce this on my local build of m-c on a new profile. Findings:

- When I load the testcase page, the page does not finish loading. None of the page's markup is shown, and I get the "stop script" infobar.
- Without taking any further action, Firefox is completely fine and usable other than the fact that the testcase page stays indefinitely loading.
- Clicking "Wait" on the infobar maintains this situation.
- Clicking "Stop it" on the infobar results in Firefox becoming extremely unresponsive, which is strange.

Comment 3

[Johann Hofmann [:johannh]]

Sorry for not responding earlier, I had the same findings as Nihanth, only that "Stop it" was able to get rid of the page just fine after a few seconds of slowness.

Do you have e10s turned on and with how many content processes? (in about:support check  Multiprocess Windows and Web Content Processes). If this is specific to non-e10s I think we can safely put it on low priority.

Comment 4

[hef]

(In reply to Johann Hofmann [:johannh] from comment #3)
> Sorry for not responding earlier, I had the same findings as Nihanth, only
> that "Stop it" was able to get rid of the page just fine after a few seconds
> of slowness.
> 
> Do you have e10s turned on and with how many content processes? (in
> about:support check  Multiprocess Windows and Web Content Processes). If
> this is specific to non-e10s I think we can safely put it on low priority.

If I understand correctly, e10s is not in release firefox yet, so I don't think I have that turned on.

In Multiprocess Windows  I see 0/1 (Disabled by add-ons)
I don't see a field for web content processes

Comment 5

[Julien Cristau [:jcristau]]

I don't feel this is worth tracking for release.  It's painful, but I also seem to be able to stop the script / close the tab and after a few seconds things go back to normal.

hef, e10s has been in release firefox for a while now, although not for all users in particular depending on whether the add-ons they are using are compatible.  In 57 old-style add-ons will be disabled which will let us enable e10s for yet more users.

Comment 6

[Johann Hofmann [:johannh]]

It seems there's already another bug for this...

Comment 7

[hef]

It's back. The behavior is a little different but the repro is the same.

firefox 77.0.1 (64-bit) on osx.

Now it doesn't crash or freeze firefox right away. I get prompted to stop a slow page. When I press stop, pages get kind weird, new pages stop loading. Tabs are able to switch but stop responding. Eventually firefox appears to crash anyway.