Suppressing alert boxes leads to NS_ERROR_NOT_AVAILABLE

VERIFIED FIXED in Firefox 43

Status

()

defect
VERIFIED FIXED
8 years ago
2 months ago

People

(Reporter: florian, Assigned: bzbarsky, Mentored)

Tracking

({regression, testcase})

Trunk
mozilla43
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox43 verified)

Details

(Whiteboard: [lang=c++], STR in comment 11 , [testday-20151127])

Attachments

(1 attachment)

Reporter

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11

Trying to call alert(x) throws an NS_ERROR_NOT_AVAILABLE exception if the checkbox to suppress further alert boxes has been checked before.

Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMWindowInternal.alert]

Reproducible: Always

Steps to Reproduce:
1. call alert() a couple times
2. check the box to suppress future alert boxes
3. call alert() again
Actual Results:  
Exception thrown, execution interrupted -> page javascript not functioning as intended

Expected Results:  
alert is ignored, javascript continues normal execution

<!doctype html>
<button id=input1>Pop alert</button>

<script>
document.getElementById('input1').addEventListener('click', function(){alert('Bang!')}, false);
</script>

Updated

8 years ago
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
This has nothing to do with the JS engine.

It also looks like this was a purposeful decision.  See the last two paragraphs of bug 61098 comment 209.
Assignee: general → nobody
Component: JavaScript Engine → DOM
QA Contact: general → general
Whiteboard: WONTFIX?
Reporter

Comment 2

8 years ago
The page I work on uses alert boxes for validation messages. Most of the times, the checkbox to suppress further alerts is already shown for the second box. Since we're not catching any exceptions right now, client-side validation gets completely broken after alerts are suppressed.
What do other browsers do in this case?
Reporter

Comment 4

8 years ago
Safari 5 and IE 8 don't seem to support suppressing alerts.
Chrome 9 does what I expected, continuing execution without showing an alert.
Opera has a "Stop scripts executing on this page" checkbox on alerts; I'm not sure what it does.
Duplicate of this bug: 651105

Comment 7

8 years ago
I'm concerned that this has been whiteboarded toward wontfix -- I believe that this is a real user-experience problem and does *not* behave the way developers expect it to behave.

jst's comments from 2003 notwithstanding, this check box should suppress alerts but not throw an exception. AFAIK, Firefox 4 is also the first moz-browser which ships with this option enabled.  It should also be noted that malware has changed significantly since 2003, and that we have run-away-script detection now, which I think complete mitigates his concern.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Fwiw, we had runaway script detection then too, iirc.

Comment 9

8 years ago
Is this bug going to not be fixed ever?
Note that confirm() has the same bug.

I think that alert() should not throw any exception (unless it is some "standard" among most of the browsers).
So when alert() is suppressed the JS code should continue without any notice.

With confirm() it's more complicated as you expect a return code from this function.
So if user suppresses a confirm() with "yes", then he is expecting all other confirm()'s to be confirmed and vice-versa (or not?).
The problem is that there could be more confirm() dialogues on the page and user expects browser to remember the choice only for one type of question (eg. "Are you hungry?" -> "Yes", but "Really delete this file?" -> "No").

So I guess the only workaround for this bug try-catching every alert() and confirm() call...
Duplicate of this bug: 681505

Comment 11

8 years ago
As I described in  Bug 681505.

After check checkbox of  "Prevent this page from creating additional dialogs,",
Browser should execute Javascript Codes which placed after the alert() statement silently(without alert box).
Google Chrome does.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox with clean profile
2. Open Error Console
3. Open attachment 555241 [details]
4. Click a button

5. When an alert box appeares,
5-1. In case of there is no checkbox of "Prevent this page from creating additional dialogs," just click "OK" button.
5-2. In case of there is a checkbox of "Prevent this page from creating additional dialogs", check the checkbox and click "OK" button.

5. Repeat Step 4 and 5(5-1/5-2) til an error massage appears in the Error Console

6. After step 5-2, Repeat 4.

Actual Results:
  An error massage appears as follow.
  Error: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMWindow.alert]
  Browser would not execute Javascript Codes which placed after the alert() statement;

Expected Results:
  No error.
  Browser should execute Javascript Codes which placed after the alert() statement silently(without alert box).

Updated

8 years ago
Blocks: alertloops
Keywords: regression, testcase
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk

Comment 12

8 years ago
from Bug 681505 comment #3
(In reply to Josh Matthews [:jdm] from comment #3)
> This should just be an easy change from |return NS_ERROR_NOT_AVAILABLE| to
> |return NS_OK| in nsGlobalWindow::Alert, nsGlobalWindow::Prompt, and
> nsGlobalWindow::Confirm.

I modified \dom\base\nsGlobalWindow.cpp with  NS_OK instead of NS_ERROR_NOT_AVAILABLE in locally .
And it worked as expected.
Reporter

Comment 13

8 years ago
It seems intuitive that a suppressed alert is simply ignored and the code thereafter is executed normally.

However, in case of confirm and prompt dialogs the user has an influence on the control flow. The only possibility to keep the code running here is to return default values, as if the user had manually cancelled (false for confirm and null for prompt). This may not work as intended for every script out there, but should be the best bet. It's also what Chrome does btw.

Comment 14

5 years ago
(In reply to Florian Lasinger from comment #13)
> […] return default values, as if the user had manually cancelled (false for
> confirm and null for prompt). This may not work as intended for every script
> out there, but should be the best bet. It's also what Chrome does btw.

I think that's the safest option (and IMHO the expected behaviour).
Whiteboard: WONTFIX?

Comment 15

5 years ago
May I know this bug will be fixed? If yes, when will it be fixed?

Or any workaround could be provided to over come the problem of all the subsequent javascript has been turn off after the return error of "NS_ERROR_NOT_AVAILABLE" ? Said for example, can we catch this error "NS_ERROR_NOT_AVAILABLE" so that can avoid javascript been turn off or can enable back the javascript?

Any solution will be much appreciated!
Thanks a lot.
Flags: needinfo?(florian)
Mentor: bugs
Whiteboard: [lang=c++]
Reporter

Comment 16

4 years ago
Not sure what the needinfo flag means and why it's associated with me. I'm just the reporter here.
Flags: needinfo?(florian)
Needinfo means that someone is being asked for information.  It can make sense to ask the reporter for information if it's something like "how do I reproduce this?".  But yeah, asking you for needinfo for comment 15 doesn't make much sense.

> can we catch this error "NS_ERROR_NOT_AVAILABLE"

Sure.  It's just an exception.  You can catch it.
Jonas, since you originally asked for the code to be this way, you get the honor of reviewing.  Note that I didn't bother differentiating between the cases when the window is no longer current and the case when it explicitly has dialogs disabled, but I could do that if you think it's worth it...
Attachment #8638564 - Flags: review?(jonas)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Comment on attachment 8638564 [details] [diff] [review]
When alerts/prompts/confirms are suppressed, just return silently instead of throwing

Review of attachment 8638564 [details] [diff] [review]:
-----------------------------------------------------------------

That looks like jst's review and not mine.
Attachment #8638564 - Flags: review?(jonas) → review?(jst)
I'm personally totally fine with silently suppressing the dialog though. Maybe stick something in the error console unless we already are logging this there as a blocked popup.
Comment on attachment 8638564 [details] [diff] [review]
When alerts/prompts/confirms are suppressed, just return silently instead of throwing

This seems totally reasonable to me. r=jst
Attachment #8638564 - Flags: review?(jst) → review+
https://hg.mozilla.org/mozilla-central/rev/06038b476e9b
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
QA Whiteboard: [good first verify]
Whiteboard: [lang=c++] → [lang=c++], STR in comment 11
Following the STR from comment 11 , I have reproduced the bug with Firefox 43.0a1(20150909030223) on Windows 7 64 bit. 

The fix is verified for latest Firefox Beta 43.0b7(20151126120800)

UA:
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:43.0) Gecko/20100101 Firefox/43.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Whiteboard: [lang=c++], STR in comment 11 → [lang=c++], STR in comment 11 , [testday-20151127]
Status: RESOLVED → VERIFIED
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.