Closed Bug 633154 Opened 13 years ago Closed 9 years ago

Suppressing alert boxes leads to NS_ERROR_NOT_AVAILABLE

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla43
Tracking Flags:
Tracking Status
firefox43 --- verified

People

(Reporter: florian, Assigned: bzbarsky, Mentored)

References

Details

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

Attachments

(1 file)

When alerts/prompts/confirms are suppressed, just return silently instead of throwing
3.27 KB, patch
jst
: review+
Details | Diff | Splinter Review 
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>
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?
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?
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.
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.
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...
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).
Blocks: alertloops
Keywords: regression, testcase
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
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.
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.
(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?
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++]
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
Closed: 9 years ago
status-firefox43: --- → fixed
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
status-firefox43: fixed → verified
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: