1180005 - a call to alert() and confirm() hangs my web application

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[geoffrey.ritchey]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150525141253

Steps to reproduce:

My gwt web application calls alert("message").  

 https://github.com/gwtproject/gwt/issues/9152#issuecomment-118079792   




Actual results:

The box is displayed but when the confirmation button is clicked, the interface locks up  (as if it is still in MODAL-DIALOG-MODE).  I reported the issue to gwt and they think the bug is an old Firefox bug that has been re-introduced.  The debugger shows it is throwing a makeAssertionError with the message "Negative entryDepth value at entry " + entryDepth

https://github.com/gwtproject/gwt/issues/9152#issuecomment-118079792   


Expected results:

No lockup of web page

Comment 1

[Thomas Broyer]

What happens is that there is concurrent execution of JS code that messes up with application state (JS variable value).

Repro case at https://jsfiddle.net/49b5gf8j/1/embedded/result/

Open the dev console and click the button, then dismiss the alert box. You may have to repeat that a few time to trigger the bug.

At some point, you'll see a strange call stack in the console:

console.trace():
  exit()
  entry0()
  checkHistoryCycle()
  doClick/<()
  entry0()
  doClick()

checkHistoryCycle is called form a setTimeout, **not** from doClick(). BTW, that `doClick/<()` notation looks suspicious.

Comment 2

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

Hi reporter,

I've tested this on the latest release(42.0) and the interface didn't locked up. Inside the console, "Use of getAttributeNode() is deprecated. Use getAttribute() instead." message is present even before I click on "Click Me" button. 
After I click the button once, I get inside the console the following:

enter: entryDepth=1 light:52:9
console.trace(): light:53
enter() light:53
entry0() light:43
checkHistoryCycle() light:88
doClick/<() light:81
entry0() light:45
doClick() light:80

exit: entryDepth=1 light:67:9
console.trace(): light:68
exit() light:68
entry0() light:47
checkHistoryCycle() light:88
doClick/<() light:81
entry0() light:45
doClick()

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

On the latest Nightly(45.0a1) however, I don't get anything inside the console after I click the "Click Me" button. I still get "Use of getAttributeNode() is deprecated. Use getAttribute() instead." message before that. The interface didn't locked up.

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20151203030226

In Chrome I get this error when clicking the button and none alert appears:
"(index):81 Ignored call to 'alert()'. The document is sandboxed, and the 'allow-modals' keyword is not set."

In IE, I get this error message inside the console, before I click the "Click Me" button:
"SCRIPT5: Access is denied."

Considering this, I find it hard to believe that this is a Firefox problem. Anyway, please try to reproduce this on the latest release(42.0) and latest Nightly(45.0a1) and provide the results.

Thanks,
Paul.

Comment 3

[Thomas Broyer]

> I've tested this on the latest release(42.0) and the interface didn't locked up.

Indeed I can't reproduce it either in 42.0 (Ubuntu package). The console shows the "bad" stacktrace but the interface doesn't lock up.

> In Chrome […]
> In IE […]
> Considering this, I find it hard to believe that this is a Firefox problem.

Are you kidding me? JSFiddle changed the way they run/show fiddles since I originally posted the repro case, and browsers have changed too since then.
Once loaded, you can open the frame in its own tab and have the code running; or you could copy/paste the script from https://jsfiddle.net/49b5gf8j/1/light/

Comment 4

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

Since Thomas didn't managed to reproduce this issue on the latest release(42.0) and latest Nightly(45.0a1) doesn't show "bad" stack trace inside the console, I will mark this issue as RESOLVED WORKSFORME.

If you encounter any issues related to this one, please feel free to reopen this bug or file a new one.

Thanks,
Paul.