Closed
Bug 681147
Opened 14 years ago
Closed 1 year ago
Investigate high number of crash signatures that have javascript: urls
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: marcia, Unassigned)
Details
Attachments
(2 files)
Discussed in the CrashKill meeting. chofmann ran a report recently which showed a high number of crash signatures that have JS urls and thought we should probe further. I have attached the txt file for review by dmandelin.
|
||
Comment 1•14 years ago
|
||
(In reply to Marcia Knous [:marcia] from comment #0)
> Created attachment 554995 [details]
> Sample report
>
> Discussed in the CrashKill meeting. chofmann ran a report recently which
> showed a high number of crash signatures that have JS urls and thought we
> should probe further. I have attached the txt file for review by dmandelin.
I don't know how to read this report format.
|
||
Comment 2•14 years ago
|
||
lines like "5.0.1 rank# 3"
show the ranking of the signature and any associated bug number with that signature.
the list of lines underneath each signature like:
6 "javascript:"""""//
5 javascript:window.parent.rmAdIframeSrc//
6 "javascript:"""""
5 javascript:window.parent.rmAdIframeSrc
2 javascript:window.parent.abanIframeSrc
show the count of crash urls where "javascript:" urls show up in the crash reports for that signature.
The key thing we want to try and figure out here is if there is something interesting in the content of of a wide variety of pages that we could abstract as a test case, or if there is something in the chrome that puts javascript: urls in the history list and then we stumble along and crash right after that action.
do we know of any use patterns like this?
|
|
||
Comment 3•14 years ago
|
||
bclary might be able to help figure out if there are any interesting patterns on the content side of this question.
Also should add that all these javascript: urls might be innocent bystanders in the crashes, but they see so pervasive across a wide variety of signatures that we should just make sure they are not behind some pattern that produces a wide variety of signatures and reflective of a deeper problem.
|
||
Comment 4•14 years ago
|
||
crashes with some form of javascript: url dropped from ~1000 to ~800 (~10-20%) on 2011-06-23 when Firefox 5 and Firefox 6 Beta released with the fix for bug 656433 landed.
Looking at yesterday's stats I see the top "urls" as:
447 "javascript:"""""
231 javascript:false;
53 javascript:''
17 javascript:false
with a handful of crashes involving javascript:raw dom related code like the window.parent stuff in comment 2 and a handful from google ads where the pattern is "javascript:""html markup with iframe"
Looking at the occurrences by branch for yesterday's stats, I see this is primarily Windows (with a handful of Mac OS X) scattered across all branches: 3.6.x, 4.x, 5.x, 6.x, 7.x, 8.x, 9.x.
The quoted "javascript:""""" stuff definitely seems weird. I'm rebuilding stuff atm, but I'll try to reproduce on my windows vm when they finish.
|
|
||
Comment 5•14 years ago
|
||
1. start debug Nightly on WinXP
2. Attach debugger
3. Open Web developer console
4. document.location.href = 'javascript:false'
ASSERTION: Uh, cx is not the current JS context!: 'cx == GetCurrentJSContext()', file c:/work/mozilla/builds/nightly/mozilla/caps/src/nsScriptSecurityManager.cpp, line 396
A funny thing happens if you do
document.location.href = '<html><body></body></html>' (or other markup)
It tries to load
jar:file:///C:/cygwin/home/bclary/bin/nightly/firefox/omni.jar!/chrome/browser/content/browser/%3Chtml%3E%3Cbody%3E%3C/body%3E%3C/html%3E
I was able to crash once in a debug build, but only after I disconnected the debugger so I didn't get the stack.
|
Assignee | |
Updated•11 years ago
|
Assignee: general → nobody
|
||
Updated•3 years ago
|
Severity: normal → S3
|
||
Comment 6•1 year ago
|
||
No crash stats in the last 6 months contain 'javascript' in their signature like those described above.
I also cannot reproduce the assertion failure from comment 5. Providing markup to document.location.href produces "Uncaught DOMException: Location.href setter: '<html><body></body></html>' is not a valid URL.".
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•