Closed
Bug 30026
Opened 26 years ago
Closed 26 years ago
browser crashes when loading this page
Categories
(Core :: DOM: HTML Parser, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: shrir, Assigned: rickg)
References
()
Details
(Whiteboard: [PDT+] fix in hand (reviewed and tested): eta to checkin 3/9)
Pls reassign to correct component if wrong.
I used yesterday's commercial bits.
Trying to visit the url mentioned above crashes the browser. The stack trace is
not much significant.
It says:
Trigger Type: Program Crash
Trigger Reason: Access violation
Thread ID:
Call Stack: (Signature = nsParser::EnableParser b8bc86f5)
nsParser::EnableParser
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 817]
CSSLoaderImpl::Cleanup
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 675]
CSSLoaderImpl::ParseSheet
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 780]
| Reporter | ||
Comment 1•26 years ago
|
||
cc: john
This is crashing in nsParser::EnableParser(), the parser checks if
eOnStop == mParserContext->mStreamListenerState but mParserContext is null!
Changing component to Parser and reassigning.
Assignee: vidur → rickg
Component: DOM Level 0 → Parser
QA Contact: desale → janc
Actually -- the parser is only responding to direction (correctly). The bug is
in the style system. Reassigning to markA.
Assignee: rickg → attinasi
PDT team: it's a trival kill, and I have the fix in hand. The crash makes me
want to fix this for beta.
Status: NEW → ASSIGNED
Keywords: beta1
Comment 5•26 years ago
|
||
Per Friday's closing PDT meeting discussion, I'm moving this up to PDT+ over the
weekend. (i.e., it is an obvious +, especially with a simple advertised fix).
Assignee: attinasi → rickg
Status: ASSIGNED → NEW
Whiteboard: [PDT+] for fix in hand w/b minus on 3/6
Oops -- my remarks were intended for a different bug. Nonetheless, I agree with
the importance of this crash (which appears to be in the style code as my
earlier comment stated) so I'll work with MarkA to fix it on monday.
Status: NEW → ASSIGNED
Comment 7•26 years ago
|
||
Removed fix in hand from status whiteboard. Will look into this today.
Whiteboard: [PDT+] for fix in hand w/b minus on 3/6 → [PDT+] w/b minus on 3/6
Comment 8•26 years ago
|
||
With Rick's help I have come up with a fix. When the parser is disabled we need
to make sure we do not ResumeParse and pop the context. Added a check for
disabled in two Parse routines and there, when disabled, short-circuited the
parse call without calling ResumeParse and then popping the context. Will
checkin today, after running pre-checkins. Reassigning to myself so I can update
to FIXED after checkin.
Assignee: rickg → attinasi
Status: ASSIGNED → NEW
Comment 9•26 years ago
|
||
According to the notes, this is fixed. Did you forget to mark this as such, or
is there a problem??
Comment 10•26 years ago
|
||
There is a problem: the change I made fixes the crash but causes some pages
(www.ebay.com) to be missing some content. I have a fix for that too but it is a
hack and I am trying to get together with Rick to make sure it is OK for now.
Please give me another day to get some of Rick's time on this. I'll update the
bug once I discuss it with him.
Status: NEW → ASSIGNED
Comment 11•26 years ago
|
||
Please open a new bug for content corrections/adjustments. This bug had the
PDT+ based on crashing. If that crash is fixed, then this should be closed, and
a new bug opened, and nominated if the content that is lost is critical and common.
Thanks,
Jim
Comment 12•26 years ago
|
||
No need to bother opening a new bug for an incomplete fix - Rick and I have
spent some time on this today and he has a complete fix for the crash that does
not break other pages (a correct fix, not my hack).
Reassigning to Rick, his ETA for checkin: 3/9
Assignee: attinasi → rickg
Status: ASSIGNED → NEW
Whiteboard: [PDT+] w/b minus on 3/6 → [PDT+] fix known: eta to checkin 3/9
| Assignee | ||
Comment 13•26 years ago
|
||
*** Bug 27235 has been marked as a duplicate of this bug. ***
| Assignee | ||
Comment 14•26 years ago
|
||
Ok the fix has been reviewed and verified by attinasi. He and Harish and I will
run with this awhile before landing. I'll land this tonight or tomorrow.
Status: NEW → ASSIGNED
| Assignee | ||
Comment 15•26 years ago
|
||
The fix seems to be working on the top 100, but I want to do more testing
tomorrow before landing. It will be ready.
Comment 16•26 years ago
|
||
Rick,
Can you update the landing plan in on the status whiteboard, and in the bug.
Thanks
Updated•26 years ago
|
Whiteboard: [PDT+] fix known: eta to checkin 3/9 → [PDT+] fix in hand (reviewed and tested): eta to checkin 3/9
| Assignee | ||
Comment 17•26 years ago
|
||
Sorry for the delay. The fix was landed on Friday on the tip. Chofmann asked me
to wait a day to land it on the branch.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•