An issue for the browser embedding of the JS Engine, not the JS Engine itself. Reassigning to Event Handling -
Assignee: rogerl → joki
QA Contact: pschwartau → janc
I think this is fairly important. It's been one of our main protections against rogue scripts. Nominating rtm
Status: NEW → ASSIGNED
Updating QA Contact.
QA Contact: janc → lorca
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.
Target Milestone: --- → Future
OS: Linux → All
Hardware: PC → All
19 years ago
Keywords: mozilla1.0, nsbeta1
*** 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?
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
18 years ago
Keywords: nsbeta1 → nsbeta1+
Target Milestone: Future → mozilla0.9.1
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
QA contact updated
QA Contact: gerardok → madhur
What happened to the ability of Escape to stop animated .gif's. That used to work - does another bug need to be filed?
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
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Moving to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Moving to 0.9.6
Looks like this won't make it in for 0.9.6.
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
Moving bugs from 0.9.7 for triaging in 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
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!
Depends on: 13350
*** Bug 128196 has been marked as a duplicate of this bug. ***
*** Bug 117539 has been marked as a duplicate of this bug. ***
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...
16 years ago
Target Milestone: mozilla1.1alpha → ---
Assignee: joki → saari
Status: ASSIGNED → NEW
QA Contact: trix → ian
*** Bug 297342 has been marked as a duplicate of this bug. ***
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.
priority: P1 Severity: major and no action for one year...
up... and adding to CC list!
Component: Event Handling → User events and focus handling
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.