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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: polidobj, Assigned: asqueella)
References
Details
(Keywords: crash, regression, testcase)
Crash Data
Attachments
(1 file)
(deleted),
application/zip
|
Details |
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
Reporter | ||
Comment 3•18 years ago
|
||
I get nothing useful from talkback either. TB25697958M
Comment 4•18 years ago
|
||
Crash already present in 1.9a1_2006110721 build.
Comment 5•18 years ago
|
||
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 ?
Comment 6•18 years ago
|
||
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
Assignee | ||
Comment 7•18 years ago
|
||
I'm on it.
Assignee | ||
Comment 8•18 years ago
|
||
So <?xul-overlay?> being inside the <overlay> causes this.
http://mxr-test.landfill.bugzilla.org/mxr-test/seamonkey/source/browser/base/content/viewSourceOverlay.xul#42
Assignee: nobody → asqueella
Summary: Crash when clicking on a link to source code → Crash when clicking on a link to source code [@ nsXULDocument::ResumeWalk()]
Assignee | ||
Comment 9•18 years ago
|
||
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
Comment 10•18 years ago
|
||
Fwiw, I think just opening view-source will trigger this.
Assignee | ||
Comment 11•18 years ago
|
||
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?
Assignee | ||
Comment 12•18 years ago
|
||
Comment 13•18 years ago
|
||
(In reply to comment #10)
> Fwiw, I think just opening view-source will trigger this.
>
Yep, It does.
Reporter | ||
Comment 14•18 years ago
|
||
fwiw bug 319654 also broke the adblock (0.5.3.042) extension. It works again since the backout.
Comment 15•18 years ago
|
||
(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.
Comment 16•18 years ago
|
||
> 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.
Assignee | ||
Comment 17•18 years ago
|
||
(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
Assignee | ||
Comment 18•18 years ago
|
||
Filed bug 360119.
Comment 19•18 years ago
|
||
This was fixed by backing out bug 319654.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment 20•18 years ago
|
||
*** Bug 360592 has been marked as a duplicate of this bug. ***
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
Updated•13 years ago
|
Crash Signature: [@ nsXULDocument::ResumeWalk()]
You need to log in
before you can comment on or make changes to this bug.
Description
•