Closed Bug 359959 Opened 18 years ago Closed 18 years ago

Crash when clicking on a link to source code [@ nsXULDocument::ResumeWalk()]

Categories

(Core :: XUL, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: polidobj, Assigned: asqueella)

References

Details

(Keywords: crash, regression, testcase)

Crash Data

Attachments

(1 file)

A crash occurs when clicking on the links in the error console to take you to the source code to see where the problem occurs. 2006110704 works 2006110804 crashes
No crash here but I get this after clicking the links Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIBoxObject.getProperty]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/bindings/textbox.xml :: :: line 102" data: no] Source file: chrome://global/content/findBar.js Line: 112
Sorry I had thought Firefox updated to the 08 build but actually was to the 07 build when I tested. With the 2006110704 build I get the above error when I click the source links With the 2006110804 build crashes with no useful info TB25697677E
I get nothing useful from talkback either. TB25697958M
Crash already present in 1.9a1_2006110721 build.
I see no crash nor warning with my "alternative" editor. However, the window does only pop up the first time I click on a link regressionwindow: works in fails in firefox-3.0a1.en-US.win32_20061107_0554pdt build (nighly) fails in firefox-3.0a1.en-US.win32_20061107_2219pdt build http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-07+04%3A00%3A00&maxdate=2006-11-07+22%3A18%3A00&cvsroot=%2Fcvsroot Bug 319654 ?
bug 319654 was backed out to check if it caused Mac orange. There should be a win32 build avalable at ~1050pst/1850utc w/o the above. Make sure to download and test that 1
I'm on it.
Assignee: nobody → asqueella
Summary: Crash when clicking on a link to source code → Crash when clicking on a link to source code [@ nsXULDocument::ResumeWalk()]
There were several issues with the patch in bug 319654, so I'll include a fix to this in a new patch there.
Component: Error Console → XP Toolkit/Widgets: XUL
Keywords: crash
Product: Firefox → Core
QA Contact: javascript.console → xptoolkit.xul
Fwiw, I think just opening view-source will trigger this.
There's also a spec issue here. Should the following code load baseMenuOverlay.xul? <overlay xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <?xul-overlay href="chrome://browser/content/baseMenuOverlay.xul"?> </overlay> It obviously does currently, but I wouldn't expect it to, since normally nodes inside <overlay> that don't match something else's id get appended inside the root element of the master document. xml-stylesheet PIs don't have effect outside prolog per the spec and in bug 319654 it's been decided that xul-overlay shouldn't have effect outside prolog either. Should that decision be revisited? Or should we go ahead and change the behavior in overlays too?
Attached file testcase (3 files zipped) (deleted) —
(In reply to comment #10) > Fwiw, I think just opening view-source will trigger this. > Yep, It does.
fwiw bug 319654 also broke the adblock (0.5.3.042) extension. It works again since the backout.
(In reply to comment #9) > There were several issues with the patch in bug 319654, so I'll include a fix > to this in a new patch there. I reopened bug 319654, because the backout did fix the orange (and because it's still backed out). I think you should attach the updated patch there, and close this bug.
> Should the following code load baseMenuOverlay.xul? > > <overlay xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> > <?xul-overlay href="chrome://browser/content/baseMenuOverlay.xul"?> > </overlay> > Are you asking whether overlays defined in other overlay files should be loaded, in which case the answer is yes, they should be, or whether an xul-overlay defined inside the root <overlay> should be loaded? I wouldn't think that this latter case would need to be supported. Regardless, the view source window should be fixed to have the pi outside of the root tag.
(In reply to comment #16) > Are you asking whether overlays defined in other overlay files should be > loaded, in which case the answer is yes, they should be, or whether an > xul-overlay defined inside the root <overlay> should be loaded? The latter. > I wouldn't > think that this latter case would need to be supported. Regardless, the view > source window should be fixed to have the pi outside of the root tag. > Thanks, I'll file a bug to fix the cases where <?xul-overlay ?> is used inside <overlay> in the tree.
Keywords: testcase
Filed bug 360119.
This was fixed by backing out bug 319654.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
*** Bug 360592 has been marked as a duplicate of this bug. ***
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
Crash Signature: [@ nsXULDocument::ResumeWalk()]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: