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

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Brian Polidoro]

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

Comment 1

[u88484]

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

Comment 2

[u88484]

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

Comment 3

[Brian Polidoro]

I get nothing useful from talkback either.  TB25697958M

Comment 4

[Ria Klaassen (not reading all bugmail)]

Crash already present in 1.9a1_2006110721 build.

Comment 5

[Peter van der Woude [:Peter6]]

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

[Peter van der Woude [:Peter6]]

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

Comment 7

[Nickolay_Ponomarev]

I'm on it.

Comment 8

[Nickolay_Ponomarev]

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

Comment 9

[Nickolay_Ponomarev]

There were several issues with the patch in bug 319654, so I'll include a fix to this in a new patch there.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Fwiw, I think just opening view-source will trigger this.

Comment 11

[Nickolay_Ponomarev]

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?

Comment 12

[Nickolay_Ponomarev]

Attachment: testcase (3 files zipped)

Comment 13

[u88484]

(In reply to comment #10)
> Fwiw, I think just opening view-source will trigger this.
> 

Yep, It does.

Comment 14

[Brian Polidoro]

fwiw bug 319654 also broke the adblock (0.5.3.042) extension.  It works again since the backout.  

Comment 15

[:Gavin Sharp [email: [e-mail]]]

(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

[Neil Deakin]

> 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.

Comment 17

[Nickolay_Ponomarev]

(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.

Comment 18

[Nickolay_Ponomarev]

Filed bug 360119.

Comment 19

[Boris Zbarsky [:bzbarsky]]

This was fixed by backing out bug 319654.

Comment 20

[Adam Guthrie]

*** Bug 360592 has been marked as a duplicate of this bug. ***