Closed Bug 302787 Opened 20 years ago Closed 11 years ago

alert() in onFocus causes infinite loop of alerts (onfocus triggered after each alert)

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 58441

People

(Reporter: mozilla, Unassigned)

References

Details

Attachments

(1 file)

testcase from comment 0
50 bytes, text/html
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8) Gecko/20050101 Firefox/1.0 Build Identifier: Deer Park Alpha 2 This web page causes an infinite loop: <HTML><BODY onFocus="alert('Hi')"></BODY></HTML> Reproducible: Always Steps to Reproduce: 1. Click on URL. Actual Results: Infinite loop requiring browser to be terminated. Expected Results: IE 5 only fires the event once.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050729 Firefox/1.0+ ID:2005072921 I see this too, but have no idea if it is expected behaviour or not.
Severity: critical → major
> I see this too, but have no idea if it is expected behaviour or not. Yes, in a way it is the expected behaviour. But under no conditions should JavaScript code be able to lock up the browser (as it does here). That's why a "while(1){}" loop is caught after a few seconds with a dialog box that offers to kill the offending script. Having to kill the entire browser (and losing all ones tabs) is not good. In fact this is worse than a crash. A crash terminates the browser and lets you start the recovery process. This lockup forces one to Ctrl-Alt-Del, which many end-users wouldn't be familiar with. These people would be left with no option but to shutdown the computer.
Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Actually this is the tip of a larger problem. Consider this code: <HTML><SCRIPT>while(1) alert('Hi');</SCRIPT><BODY></BODY></HTML> or click on: http://neil.fraser.name/crash2.html That will cause Mozilla (Deer Park Alpha 2), IE (6) and Opera (8) to lock up. This isn't good.
Yes, I'll agree with that. The proper solution here isn't the onfocus issue, it's alert spam in general. *** This bug has been marked as a duplicate of 253239 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
The more specific problem with onfocus is covered by bug 354089.
This isn't a dup of bug 253239. Fixing that bug (allowing users to escape infinite loops of alerts) wouldn't make this bug go away; it would just make it less severe. I don't think the patch in bug 354089 helped here, at least on Mac... Similar bugs include bug 304634, bug 279819, bug 112294, and bug 210240.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Summary: alert() in onFocus causes infinite loop → alert() in onFocus causes infinite loop of alerts (onfocus triggered after each alert)
IMO solution is to not trigger onblur/onfocus when alert() or prompt() is executed. I dont see any reason to trigger those event when alert()/prompt() is executed.
(In reply to comment #9) > IMO solution is to not trigger onblur/onfocus when alert() or prompt() is > executed. I disagree, unless alert and prompt are changed to use the notification bar or such method not opening a new dialog. I'd rather have it so that alert and prompt don't work at all from onfocus. onblur is different (and has been fixed lately).
Visit this field: <input type=text onfocus="alert('foo')" /> Welcome to hell. The solution is to allow the tab to be closed even if the alert is up. Duh. Unfortunately, that doesn't work, and the solution is to kill the whole app (Firefox doesn't even respond to the "kill window" from the window manager, much less close the tab) Application Basics Name Firefox Version 3.6.13 about:buildconfig Build platform target x86_64-unknown-linux-gnu Build tools Compiler Version Compiler flags gcc gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -g -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions c++ gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -g -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions Configure arguments --build=x86_64-linux-gnu --prefix=/usr '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' --sysconfdir=/etc --localstatedir=/var '--libexecdir=/usr/lib/firefox' --disable-maintainer-mode --disable-dependency-tracking --disable-silent-rules --srcdir=. --enable-optimize --enable-ipc --enable-tests --enable-mochitest --disable-system-cairo --disable-system-sqlite --without-system-nspr --without-system-nss --enable-crashreporter --disable-debug --with-user-appdir=.mozilla --without-system-jpeg --without-system-zlib --enable-system-myspell --disable-composer --disable-elf-dynstr-gc --disable-gtktest --disable-install-strip --disable-installer --disable-ldap --disable-mailnews --disable-profilesharing --disable-strip --disable-strip-libs --disable-tests --disable-mochitest --disable-updater --disable-xprint --enable-application=browser --enable-canvas --enable-default-toolkit=cairo-gtk2 --enable-gnomevfs --enable-pango --enable-postscript --enable-svg --enable-mathml --enable-xft --enable-xinerama --enable-extensions=default,-reporter --enable-safe-browsing --enable-single-profile --with-distribution-id=com.ubuntu --enable-startup-notification --enable-official-branding
Firefox 4 allows tabs to be closed even while JS alerts are up :)
(In reply to Jesse Ruderman from comment #14) > Firefox 4 allows tabs to be closed even while JS alerts are up :) A minimal single-alert testcase does allow the tab to be closed. However, the testcase in this bug ("testcase from comment 0") fails in the way JeffEvarts describes above. The tab becomes unresponsive, refuses to close, and Firefox itself won't even close (on OS X), and needs to be terminated.
URL: http://neil.fraser.name/crash.html
In Nightly you can just click Back. So that's nice. But if there's no previous page to go Back to, the behavior is still very weird. I can click the "close tab" X but it doesn't immediately close the tab; after that, if I click OK on the alert, I still get a new alert (which seems wrong); I can switch to other tabs but then I can't switch back. Also: in Nightly this apparently doesn't trigger the "prevent additional dialogs" checkbox. So that's weird too. I tried it in a clean profile.
Clicking the "close tab" X thrice or more ,once the alert with 'Hi', appears gives a NSGlue_Assertion ASSERTION: event for content that isn't in a document: 'doc', file <path to>/mozilla-src/layout/base/nsPresShell.cpp, line 6603 in a FF Debug Build on x86 Vista (src's few weeks older than latest mozilla-central)
Status: REOPENED → RESOLVED
Closed: 20 years ago → 11 years ago
QA Whiteboard: [bugday-20140512]
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: