Open
Bug 51139
Opened 24 years ago
Updated 5 months ago
ESC/Stop needs to stop javascript
Categories
(Core :: DOM: UI Events & Focus Handling, enhancement, P5)
Core
DOM: UI Events & Focus Handling
Tracking
()
NEW
People
(Reporter: jmd, Unassigned)
References
Details
(Whiteboard: [rtm-])
Attachments
(1 file)
710 bytes,
text/html
|
Details |
load attached file... observe you are screwed... only way i found to stop the javascript was ^C'ing mozilla... (for those nervous about loading the JS now, it simply bounces your mozilla window around, no harm done). note that JS can be much more obtrusive then this... ESC/stop should stop all javascript on the page from executing.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 3•24 years ago
|
||
An issue for the browser embedding of the JS Engine, not the JS Engine itself. Reassigning to Event Handling -
Assignee: rogerl → joki
Component: Javascript Engine → Event Handling
QA Contact: pschwartau → janc
Comment 4•24 years ago
|
||
I think this is fairly important. It's been one of our main protections against rogue scripts. Nominating rtm
Status: NEW → ASSIGNED
Keywords: rtm
Comment 6•24 years ago
|
||
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Whiteboard: [rtm-]
Target Milestone: --- → Future
Comment 7•24 years ago
|
||
I think "ESC/stop should stop all javascript on the page from executing" is overdoing it... it's too easy to hit esc/stop when you're not trying to prevent scripts on the page from running. Stopping the currently running script on ESC might make sense, but I think this is really a dup of bug 60323.
OS: Linux → All
Hardware: PC → All
Keywords: mozilla1.0,
nsbeta1
Summary: ESC needs to stop javascript → ESC/Stop needs to stop javascript
*** Bug 56250 has been marked as a duplicate of this bug. ***
Note that stopping currently running code isn't sufficient - there could be repeated setTimeout calls doing something bad. See the duplicate bug.
Johnny, should this be your bug? Or is Event Handling correct place?
Comment 11•24 years ago
|
||
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Updated•24 years ago
|
Comment 12•24 years ago
|
||
setting TM to 0.9.2 per PDT triage (however, you can check it in into 0.9.1 by 18/May/01 11:59pm or into 0.9.2 trunk when it opens)
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Updated•24 years ago
|
Priority: P3 → P2
Updated•24 years ago
|
Priority: P2 → P1
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 14•24 years ago
|
||
What happened to the ability of Escape to stop animated .gif's. That used to work - does another bug need to be filed?
Comment 15•24 years ago
|
||
Some web pages use javascript for links or form submission, and if pressing esc to stop animations (or page load) also disables javascript, those pages will break completely. Left-clicking, pressing enter, or pressing space to press a button in the content area should reactivate javascript if this is implemented. aaronl: Esc no longer stopping animations is bug 70030.
Comment 16•23 years ago
|
||
Doesn't look like this is getting fixed before the freeze tomorrow night. Pushing out a milestone. Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Comment 19•23 years ago
|
||
Moving to 0.9.6
Comment 20•23 years ago
|
||
Looks like this won't make it in for 0.9.6.
Comment 21•23 years ago
|
||
0.9.6 has passed, moving to 0.9.7. Load balancing 0.9.7 list shortly
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Comment 22•23 years ago
|
||
And how to stop loading without stopping JavaScript??
Comment 23•23 years ago
|
||
Moving bugs from 0.9.7 for triaging in 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Comment 24•23 years ago
|
||
Unfortunately, there is an important difference between how javascript is executed in mozilla vs. Nav 4. In Nav 4, javascript executed on a separate 'javascript' thread. However, in mozilla *all* javascript is executed synchronously on the UI thread! This means that while javascript is executing ALL UI INTERACTIVITY STOPS! So, there is no way to receive the 'ESC' key, or to press the 'Stop' button. This fact limits the type of UI that we can expose :-( Currently, we have a dialog box that pops up after a specified number of backwards branches within javascript... But clearly, with the attached test case, this is not sufficient...
Comment 25•23 years ago
|
||
wrt. comment #15 by Jesse Ruderman, imho it is a very good idea to be able to stop a form submission by pressing ESC. More often than not, forms are not that intuitive, and/or I find that I accidentically am submitting a form by hitting the RETURN or even the SPACE key, depending on context. I'd very much like to stop form submission in those cases, and I find it much easier to mistakenly hit the space bar instead of the ESC key as someone else noted. Btw, not being able to stop JS execution allows for complete takeover by rogue scripts as someone already noted elsewhere, and would imho make running Mozilla a major security risk. I'm voting for getting this bug fixed. Thanks!
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 26•23 years ago
|
||
As stated ("ESC/stop should stop all javascript on the page from executing"), this bug is not 4xp. Netscape 4.77 only stops the currently running script, and only if the script has not created a dialog. I suggest that this bug be changed to "Esc/Stop should stop currently running javascript". It would be reasonable to also kill any active JS timers and disable mouseover events for the page. a_geek: I wasn't talking about allowing you to stop a form submission that you triggered accidentally; you can already do that by pressing escape. I was saying that if pressing escape *permanently* disabled javascript on the page, you might not be able to submit a form after filling it out. This bug is only a denail-of-service attack, and it's not the only one Mozilla is vulnerable to. See bug 30942 for CPU-hogging DoSes, bug 70821 for RAM- hogging DoSes, and bug 59314 for DoSes involving modal dialogs. I'm not aware of any Win32 browser that has *any* of those DoSes blocked. The only DoSes I consider important to fix are ones that are commonly abused by advertisers, such as the ability to create "hydra" pop-up ads that are impossible to close. I'm making this bug depend on bug 13350, "DOM needs to police JS infinite loops, schedule garbage collection", because bug 13350 comment 0 mentions "letting the user hit Stop".
Depends on: 13350
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.1
![]() |
||
Comment 27•23 years ago
|
||
*** Bug 128196 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
QA Contact: madhur → rakeshmishra
Comment 28•22 years ago
|
||
*** Bug 117539 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
QA Contact: rakeshmishra → trix
Comment 29•22 years ago
|
||
Agree with Comment #26. Mozilla shouldnt stop JS execution (all flexability and behaviour handlers) after ESC. We can try to clearly stop actual behaviour but only if we're sure it wont destroy normall scripts work, otherway i suggest marking this as WONTFIX. By the way - TM should be changed, also severity and priority...
Updated•22 years ago
|
Target Milestone: mozilla1.1alpha → ---
Comment 31•21 years ago
|
||
See also bug 59314 or bug 61098 for stopping scripts like while(1)alert("Hi!").
Comment 32•20 years ago
|
||
*** Bug 297342 has been marked as a duplicate of this bug. ***
Comment 33•20 years ago
|
||
Let me just say this: In java, running multiple threads increases performance, but does spend an extra one or two percent cpu (no big deal at all). If the js were ran in separate threads (ui thread, and a page thread), then the performance of the js engine would be increased, and the stop button to kill scripts would be feasible.
Comment 34•18 years ago
|
||
priority: P1 Severity: major and no action for one year...
Updated•18 years ago
|
Assignee: saari → events
Priority: P1 → --
Comment 35•17 years ago
|
||
ping...
Comment 36•17 years ago
|
||
pong...
Comment 37•16 years ago
|
||
up... and adding to CC list!
Updated•15 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Assignee | ||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
Comment 38•3 years ago
|
||
ESC still does not stop JS in the latest Firefox version, but we do have the infobar that offers the user to Stop the page from slowing down the browser.
Severity: major → S3
Updated•5 months ago
|
Severity: S3 → S4
Type: defect → enhancement
Priority: -- → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•