There should be a delay between successive "alert" boxes

[Miguel Diago]

Binary package hint: firefox-3.0

There are some "joke" websites which don't let the visitor close the current window or tab by showing him infinite alert boxes generated with Javascript.

For example, visit www.own3d.es (***CAUTION: contains _gay pornography_ and Firefox process must be killed to exit the site***). I am also attaching its source code in a comment.

I think that Firefox should be able to detect this kind of situations and insert a short delay between the alert boxes to allow the user to close the window.

ProblemType: Bug
Architecture: i386
Date: Tue Jun 24 00:43:45 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: nvidia
Package: firefox-3.0 3.0+nobinonly-0ubuntu0.8.04.1
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=es_ES.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-19-generic i686

[Pschwartau (pschwartau)]

Browser, not engine. Reassigning to Browser-General for consideration -

[Doronr (doronr)]

making rfe.

[Jruderman (jruderman)]

dup of some part of bug 22049...

[Doronr (doronr)]

DOM 0 then it is.

[Jst (jst)]

Nice to have but hard to do with the threading model used in mozilla. Not high
priority --> Future

[Jruderman (jruderman)]

See bug 59314 for another suggestion as to how to prevent DoS attacks using
modal dialogs. In that bug, window-modal dialogs would be replaced with
content-modal dialogs, so that the user could still leave the page or at least
close the window.

Note that many dialogs besides page javascript alerts are currently modal --
the "connection refused" alert is a good example. Bug 28586 would eliminate at
least some of the networking-error alerts.

[Jruderman (jruderman)]

Hmm, and don't forget the Basic Auth dialog. That one isn't going away anytime
soon.

[Netdragon (netdragon)]

*** Bug 128196 has been marked as a duplicate of this bug. ***

[Jruderman (jruderman)]

*** Bug 156346 has been marked as a duplicate of this bug. ***

[Haferfrost (haferfrost)]

I think this is really a common problem for web-developers. I've fallen into
this trap several times myself (accidentally created an infite loop around my
debugging alert()). But instead of aborting all scripts, I'd like to have
something similar to the "A script on this page is causing Mozilla to run slow"
message with the option to abort the script. As a trigger for this event I would
suggest something like this:

When an alert is closed, note the time of the close. When a new alert pops up,
compute the difference between the current time and the close time of the
previous alert. If it is below a sensible threshold (let's say 5 seconds),
increase a counter. If it is above the threshold, reset the counter. If the
counter reaches 10, fire the dialog "A script on this page is creating alert()
boxes at an alarming rate. This could make your browser unusable. Abort the script?"

In case the description doesn't make this clear. The box should fire if several
times in a row the time between alerts is too short to click
Stop/Close/Back/Whatever.

[Jst (jst)]

Mass-reassigning bugs to <email address hidden>

[Exe-footut (exe-footut)]

Example:
http://megajocke.y2.org/post/oops.html

Don't open it if you have something important open in the browser.

[Matti-mversen (matti-mversen)]

*** Bug 213586 has been marked as a duplicate of this bug. ***

[Jruderman (jruderman)]

*** Bug 66097 has been marked as a duplicate of this bug. ***

[Jruderman (jruderman)]

*** Bug 215453 has been marked as a duplicate of this bug. ***

[Jo-hermans (jo-hermans)]

*** Bug 218608 has been marked as a duplicate of this bug. ***

[Johan-buret (johan-buret)]

IMHO, a javascript blocker that popups under restrictive conditions is OK but
not enough. An accelerator such as Ctrl+Pause on PCs, and whatever fits on Macs,
must be provided.

http://www.stremler.net/evil_js.html

[Sgautherie-bz (sgautherie-bz)]

Acting on Duplicate resolution from bug 66097 comment 16:

*Moving 'Blocks: bug 140346' from bug 66097 to bug 61098.
 (Take further action as needed.)

[Bugzilla-accessibleinter (bugzilla-accessibleinter)]

*** Bug 219345 has been marked as a duplicate of this bug. ***

[Spam-minneboken (spam-minneboken)]

*** Bug 241605 has been marked as a duplicate of this bug. ***

[Spam-minneboken (spam-minneboken)]

*** Bug 240311 has been marked as a duplicate of this bug. ***

[Spam-minneboken (spam-minneboken)]

*** Bug 251227 has been marked as a duplicate of this bug. ***

[Jruderman (jruderman)]

*** Bug 249360 has been marked as a duplicate of this bug. ***

[Felix Miata (mrmazda)]

*** Bug 258585 has been marked as a duplicate of this bug. ***

[Christian Biesinger (cbiesinger)]

*** Bug 261950 has been marked as a duplicate of this bug. ***

[Matti-mversen (matti-mversen)]

*** Bug 270391 has been marked as a duplicate of this bug. ***

[Philringnalda (philringnalda)]

*** Bug 276080 has been marked as a duplicate of this bug. ***

[Gavin Sharp (gavin-sharp)]

*** Bug 123308 has been marked as a duplicate of this bug. ***

[Gavin Sharp (gavin-sharp)]

*** Bug 261390 has been marked as a duplicate of this bug. ***

[Gavin Sharp (gavin-sharp)]

*** Bug 136324 has been marked as a duplicate of this bug. ***

[Philringnalda (philringnalda)]

*** Bug 281145 has been marked as a duplicate of this bug. ***

[Philringnalda (philringnalda)]

*** Bug 283838 has been marked as a duplicate of this bug. ***

[Matti-mversen (matti-mversen)]

*** Bug 286400 has been marked as a duplicate of this bug. ***

[Bugzilla-mozilla (bugzilla-mozilla)]

Given the amount of dupes, this is a highly requested feature. Actually, it
would be a lot easier to implement a Javascript function that stops this,
accessable through this JavaScript console. In this respect, a short-term
solution wouldn't require any UI changes. I still have this blasted Javascript
alert loop in one of my windows (unfix.org/~jeroen/archive/javascript_loop.html
if you're interested in having an non-functioning browser window), as I was
searching Google for such a JS command.

BTW, I do like <email address hidden>'s solution from comment #10 as a longer term
solution.

[Edward Z. Yang (ezyang)]

*** Bug 304496 has been marked as a duplicate of this bug. ***

[Edward Z. Yang (ezyang)]

(In reply to comment #5)
> Nice to have but hard to do with the threading model used in mozilla. Not high
> priority --> Future

That's interesting, because I thought that it would be easy to implement: just
use the same feature that lets Mozilla abort scripts that are taking too long to
execute...

By the way, sorry about the dupe.

[Edward Z. Yang (ezyang)]

Created an attachment (id=192603)
Don't click here unless you want your browser to crash. Proof of concept.
Especially annoying if you have lots of tabs.

Basically pops up alert boxes that say 'This alert box will never go away.' and
'The only way you can get rid of this box is by terminating the browser
process.'

[Jason-barnabe-gmail (jason-barnabe-gmail)]

How do you determine that the alert will never go away?

[Edward Z. Yang (ezyang)]

(In reply to comment #38)
> How do you determine that the alert will never go away?

In theory, it shouldn't end (the loop is on a true, i.e. while(true), which, of
course, will never evaluate to false. In practice, these loops can be used, but
they're generally stopped via a break statement).

If you don't trust me, you can try it and then keep on pressing OK. For
practical reasons, let's make 20 equal infinity.

[Jason-barnabe-gmail (jason-barnabe-gmail)]

No, I mean how does Mozilla know that the loop will never end? It's easy enough
if it's just

while (true) {
  alert("");
}

but if it's in the form of

while (true) {
  if (someFunction()) {
    alert("");
  } else {
    break;
  }
}

how would you determine that someFunction() will ever return false? See
http://en.wikipedia.org/wiki/Halting_problem

The "taking too long to execute" feature I'm guessing just figures that the
script has been running too long rather than determining that it's an infinite
loop. When you loop an alert(), the script isn't executing most of the time,
it's just waiting for the user to press OK. The idea in comment 10 is similar,
but definitely not the same as the "taking too long" feature.

[Brendan-mozilla (brendan-mozilla)]

Everyone please chill. This bug will get fixed or I'll become a pirate and sail off into infamy, fight for the little people, and drink hard(er).

/be

[Photodeus (photodeus)]

I was just reading Slashdot and bugtraq today about a so called full disclosue of a Microsoft vulnerability, released by a "Google research engineer" after 5 days of no patch from MS. Sort of blackmail because a fix wasn't released fast enough.

We already have the full disclosure, but not the exposure. All it takes is for someone crazy to start a "Crash Firefox day" group on Facebook and distribute simple scripts to insert into innocent looking places.

This could possibly destroy all credibility of Firefox in most corporate and government organizations.
Luckily nobody does that. (And seriously, I absolutely don't want this)

A semi-philosophical and rhetorical question:
How smart is it to leave a ticking time bomb for this long and not push a fix sooner than later? And this goes of course for everything that is a remote denial of services attack which will cause loss of unsaved work.

I can say I've been hit by this more time than I can count, add-ons such as NoScript and AlertCheck are absolute life savers.
Sorry for ranting here.

[Jo-hermans (jo-hermans)]

Seppo, this is not a discussion board. Please don't add any comments that don't help to solve the bug in itself. Or do you have a patch that you want to share with the world ? I refer to comment 291 (look up on Wikipedia who Brendan Eich is).

[Trent Waddington (qg)]

Jo, there's been dozens of patches put forward to fix this bugs over the years. The Mozilla bureaucracy prevents any of them getting accepted.

[Photodeus (photodeus)]

I use a proper add-on so therefore I can safely chill.

@Jo, I know very well who Brendan is. Even if he was God of JavaScript himself, the fact remains "chilling" can be costly in times like these where bad reputation spreads like wildfire and gaining back that lost market share can become impossible once the sh*t hits the fan. Chill and wait or take a proactive response.

I'm sorry for again breaking netiquette and replying in this thread. From now on I will take this to an appropriate discussion board and not revisit this anymore.

[Timwi (timwi)]

> I refer to comment 291 (look up on Wikipedia who Brendan Eich is).

What a monumentally misplaced appeal to authority :)

[Brendan-mozilla (brendan-mozilla)]

Arguments from authority are not what I had in mind with comment 291. I was trying to appeal to the common goal of getting this bug fixed, which is less likely if there are noisy and abrasive comments. I was also throwing my support behind this bug getting fixed, where my authority may count for something, and where I also may be able to help with code-level issues.

But in any case, non-coding talk that amounts to sarcasm or posturing in bug comments do not help get this bug fixed.

Gravis, you were way out of line and you added nothing of value in all of comment 277, comment 279, and even comment 287 which repeated links to add-ons mentioned already in comment 263 and comment 266. You seem like the model of a "poisonous person" (http://video.google.com/videoplay?docid=-4216011961522818645#). I'll back beltzner in revoking your bugzilla access if I see anything but usefully technical comments from you.

Seppo, bugzilla bugs are not "threads" in a "discussion board". Frustration is no excuse. I'm annoyed this bug is still unfixed, but I'm telling you, you are not helping. My comments at this point aren't helping either, so I'm going to shut up and work backstage to help get a reviewable patch up. But I have one request flag to set here:

This is clearly not just a hot button issue for a few people -- it's a common enough usability bug (developer accident as much as malicious DoS attack), and it is a competitive issue. I think it should be fixed for Firefox 4. Nominating blocking.

We haven't heard from faaborg since comment 276, and it isn't obvious dolske or whoever can do what faaborg said to do saw that amid all the noise. Maybe dolske should take assignment of this bug. Probably better to file dependency bugs and do the work in them, without all this noise.

/be

[Faaborg (faaborg)]

>We haven't heard from faaborg since comment 276

Sorry about that, here's a general update. As you are aware (but perhaps not the masses of people cc'd on this bug) there are two separate issues:

1) providing a check box to suppress future alerts (this bug)
2) making the alerts themselves tab modal (separate bug, which has a work in progress patch from dolske)

These don't necessarily have to land in sequence, although I think we should get both done before Firefox 4, since even with a tab modal alert you may wish to view or interact with content after the first alert is fired.

I have mockups complete that I need to post them to dolske's bug when he is ready to implement the UI, essentially we are going to be using the same panels we are creating for the rest of our notifications, but placed in the center of the content area. I need to ping Neil about making some changes to our panel support to allow for this (we can get it to move with its parent, but we need an attribute to control this, details in bug 554925)

For this bug, someone is going to need to take up the patch to land the checkbox (which could appear in either a window modal or tab modal dialog box). I spoke to jst about it had he indicated that aside from tweaks to the code and getting tests to pass, there isn't a more fundamental reason why it can't land.

>amid all the noise

indeed, sorry for not commenting more regularly with updates. It's not that work isn't happening, just that this bug has turned into more of a ranting message board and is mostly being avoided.

Also on a more personal level to the people ranting: for what it's worth we are working on the weekend, and pretty clearly not playing video games.

[Dolske (dolske)]

(In reply to comment #298)

> 1) providing a check box to suppress future alerts (this bug)
> 2) making the alerts themselves tab modal (separate bug, which has a work in
> progress patch from dolske)
>
> These don't necessarily have to land in sequence, although I think we should
> get both done before Firefox 4, since even with a tab modal alert you may wish
> to view or interact with content after the first alert is fired.

I am currently pushing to get the tab-modal work (bug 59314) done for Beta 1 or Beta 2 (ie, within the next ~month). I think that will resolve the most common issues people have with modal prompts, though the ability to disable prompts without closing the tab will still be useful in some cases.

[Keul (mapeditor)]

Tab modal will in fact be even more efficient than using check-box like opera/chrome because the attack is based on modal dialog, that is not only alert/confirm/prompt dialog but also all others modal dialog (security warning/http authentication/...)

For special cases/developpers,we can maybe add an about:config value.

[longsonr (longsonr)]

*** Bug 571873 has been marked as a duplicate of this bug. ***

[Moz-jeka (moz-jeka)]

*** Bug 562255 has been marked as a duplicate of this bug. ***

[Jst (jst)]

Created attachment 462681
Updated to tip, with various tweaks

This is an updated patch for this bug, based on the previous versions in this bug. The changes are that this stores the time limit in a pref (primarily so that we can disable this during mochitest runs), deals with window.print(), renames some things, and some other minor tweaks. This still needs tweaks to tracking modal dialog state properly while showing the print dialog at least...

[Jst (jst)]

Created attachment 472820
Updated fix.

This is a yet more updated version of Nochum's fix for this bug. This deals with alert(), confirm(), prompt(), showModalDialog(), and print(), and this makes the time limit settable in a pref and makes our mochitest harness set that pref to 0 to disable this in our automated tests which trigger extra dialogs in certain cases.

Jonas, I've looked this over, but I could appreciate another look here.

[Jst (jst)]

This actually needs to block beta6 since the patch adds localizable strings, and is a feature addition, in a way.

[Jonas-sicking (jonas-sicking)]

Comment on attachment 472820
Updated fix.

>diff --git a/dom/base/nsGlobalWindow.cpp b/dom/base/nsGlobalWindow.cpp
>+ if (sSuccessiveDialogTimeLimit == 0) {
>+ PRInt32 t = nsContentUtils::GetIntPref("dom.successive_dialog_time_limit",
>+ SUCCESSIVE_DIALOG_TIME_LIMIT);
>+
>+ if (t <= 0) {
>+ sSuccessiveDialogTimeLimit = PR_INT32_MIN;
>+ } else {
>+ sSuccessiveDialogTimeLimit = t;
>+ }
>+ }
> }

So is the intent that 0 means "don't have a time limit"? If so, leaving it at 0 or a negative value should work. So always setting sSuccessiveDialogTimeLimit to the pref value seems like it should work.

>+nsGlobalWindow::DialogBlockingEnabled()
>+{
>+ nsGlobalWindow *topWindow = GetTop();
>+ if (!topWindow) {
>+ NS_ERROR("DialogBlockingEnabled() called without a top window?");
>+
>+ return false;
>+ }
>+
>+ topWindow = topWindow->GetCurrentInnerWindowInternal();
>+ if (!topWindow ||
>+ topWindow->mLastDialogQuitTime.IsNull() ||
>+ nsContentUtils::IsCallerTrustedForCapability("UniversalXPConnect")) {
>+ return false;
>+ }
>+
>+ TimeDuration dialogDuration(TimeStamp::Now() -
>+ topWindow->mLastDialogQuitTime);
>+ PRBool underDuration =
>+ dialogDuration.ToSeconds() < sSuccessiveDialogTimeLimit;
>+ if (underDuration) {
>+ if(topWindow->GetPopupControlState() > openControlled) {
>+ topWindow->mDialogAbuseCount++;
>+
>+ return true;
>+ }
>+ topWindow->mDialogAbuseCount++;
>+
>+ return topWindow->mDialogAbuseCount > MAX_DIALOG_COUNT;
>+ }

Just do:

topWindow->mDialogAbuseCount++

return topWindow->GetPopupControlState() > openControlled ||
       topWindow->mDialogAbuseCount > MAX_DIALOG_COUNT;

>+nsGlobalWindow::IsDialogDisabled()
>+{
>+ nsGlobalWindow *topWindow = GetTop();
>+ if (!topWindow) {
>+ NS_ERROR("IsDialogDisabled() called without a top window?");
>+
>+ return true;
>+ }
>+
>+ topWindow = topWindow->GetCurrentInnerWindowInternal();
>+
>+ return !topWindow ||
>+ (topWindow->mDialogDisabled &&
>+ (topWindow->GetPopupControlState() > openAllowed ||
>+ topWindow->mDialogAbuseCount >= MAX_DIALOG_COUNT));
>+}

Why openAllowed here, but openControlled in nsGlobalWindow::DialogBlockingEnabled?

Also, it would be nice to have better names for these functions. There is no intuitive difference between

DialogBlockingEnabled
IsDialogDisabled
AllowDialog

Based only on the names I would have expected the first two to always return the same thing, and the last to always return the opposite of the others. At the very least, document them thoroughly in the header file.

Maybe rename DialogBlockingEnabled to DialogOpenAttempted and AllowDialog to ConfirmDialogAllowed.

Also, some more tests would be nice.

r=me with that

[Highmind63 (highmind63)]

Why does this depend on bug 391834?

[Jst (jst)]

I don't see how it does, removing dependency.

[Jst (jst)]

Created attachment 475374
Followup fixes.

Jonas, this adds tests, adds a few changes that are needed to be able to test this (more Enter/LeaveModalState, use the prompt service, don't get a prompter that's already been created), and renames and comments a few things per your comments.

This does not explain openAllowed/Controlled/Abused, I have not had the time to investigate their meaning, and probably won't have time for beta7 to do that.

[Jonas-sicking (jonas-sicking)]

Comment on attachment 475374
Followup fixes.

>+ // Returns true if we've reached the state in this top level window
>+ // where we ask the user if further dialogs should be blocked.
> bool DialogBlockingEnabled();

I still don't think this function name is very descriptive since there is no indication that it will increase the count of dialogs that have been opened and stuff like that. This is also not mentioned in the comment. Something like

// Call this when a modal dialog is about to be opened.
// Returns true if we've reached the state in this top level window
// where we ask the user if further dialogs should be blocked.
bool DialogOpenAttempted();

r=me with that.

[Jst (jst)]

Created attachment 476153
For checkin.

[Jst (jst)]

Checked in:

http://hg.mozilla.org/mozilla-central/rev/e036427942ff

[Jst (jst)]

Marking FIXED. For any followup issues, please file *new* bugs and mark them dependent on this bug!

[Bthaxor (bthaxor)]

How come the ' Description of how to close a tab with a running endless alert loop.' attachment still breaks this?

[Jst (jst)]

bthaxor, *please* file a separate bug with appropriate steps to reproduce what you're seeing etc. This bug by no means covers every aspect of this problem, further issues should be tracked in individual bugs.

[Bthaxor (bthaxor)]

Sorry, I just thought it would be best to post this here since the attachment exists in this bug - will do.

[Bijumaillist (bijumaillist)]

MAX_DIALOG_COUNT = 10 is only showing the check box at 12th prompt

javascript:i=1;while(1)alert(i++);

I wish I am able to see the check box in the very first prompt.
Or at least show it in the 3rd prompt. 12th is too long to wait.

Or provide a about:config item.

[Zéfling (zefling)]

Why 12 and not 2 or 3 ?

[Jst (jst)]

Again, please file new bugs on details surrounding this. This bug is FIXED.

[Bijumaillist (bijumaillist)]

For evil website there is a technique to circumvent this bug fix
see attachment 476707 at bug 597934

[Bijumaillist (bijumaillist)]

(In reply to comment #318)
> Why 12 and not 2 or 3 ?

Submitted
Bug 598536 -
Please show "Prevent...creating addi. dialogs" at second alert/confirm/prompt

[Mardeg (mardeg)]

*** Bug 606671 has been marked as a duplicate of this bug. ***

[Ed-membled (ed-membled)]

Thanks for fixing this in the source tree. Is the fix expected to appear in the next Firefox 3.7 update, and/or the Firefox 4 beta?

[Mardeg (mardeg)]

*** Bug 607276 has been marked as a duplicate of this bug. ***

[Mardeg (mardeg)]

*** Bug 607919 has been marked as a duplicate of this bug. ***

[Micah Gersten (micahg)]

This is fixed in Natty now with Firefox 4.0b7

[Ms2ger (ms2ger)]

*** Bug 536783 has been marked as a duplicate of this bug. ***

[Matti-mversen (matti-mversen)]

*** Bug 300377 has been marked as a duplicate of this bug. ***

[Raziahmed345 (raziahmed345)]

I think both of these should be eventually implemented.
<a href="https://www.newsboxwithrazi.com/2021/11/what-is-freelancing-and-how-does-it-work.html">what is freelancing and how does it work </a>

[Raziahmed345 (raziahmed345)]

(In reply to raziahmed from comment #328)
> I think both of these should be eventually implemented.
https://www.newsboxwithrazi.com/2021/11/what-is-freelancing-and-how-does-it-work.html