637131 - Unexpected load of chrome://browser/content/browser.xul when using the Web Console (Ctrl-Maj-K)

Status: RESOLVED FIXED

(DevTools :: General, defect)

Description

[Ophir LOJKINE]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b12) Gecko/20100101 Firefox/4.0b12

On http://ophir.lojkine.free.fr/wikipedit/, trying to call a certain function via the Web Console (Ctrl-Maj-K) makes Firefox load chrome://browser/content/browser.xul.

Reproducible: Always

Steps to Reproduce:
1.Load http://ophir.lojkine.free.fr/wikipedit/
2. Call the web console (type Ctrl-Maj-K)
3. In the web console, type "article()", and validate
Actual Results:  
Loads chrome://browser/content/browser.xul in the main page.

Expected Results:  
Loading http://ophir.lojkine.free.fr/wikipedit/#something

The bug only occurs with javascript functions doing something like window.location="#Something"

Comment 1

[Alice0775 White]

Confirmed on
http://hg.mozilla.org/mozilla-central/rev/d708c2fa7fea
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110226 Firefox/4.0b13pre ID:20110226030401

Comment 2

[David Dahl :ddahl]

Not unexpected, firebug lite is loaded, with this function:

this.normalizeURL=function(url){if(!url){return""
}if(url.length<255){url=url.replace(/[^\/]+\/\.\.\//,"","g");
url=url.replace(/#.*/,"");
url=url.replace(/file:\/([^\/])/g,"file:///$1");
if(url.indexOf("chrome:")==0){var m=reChromeCase.exec(url);
if(m){url="chrome://"+m[1].toLowerCase()+"/"+m[2]
}}}return url
};

A content script then calls document.location = url

Comment 3

[Ophir LOJKINE]

No! This bug is not resolved! I removed firebug and the bug is still present. Please mark the bug as unresolved.

Comment 4

[Ophir LOJKINE]

I created a simpler script to demonstrate the bug:
http://ophir.lojkine.free.fr/bug.html

Comment 5

[Ophir LOJKINE]

Steps to Reproduce:
1.Load http://ophir.lojkine.free.fr/bug.html
2. Call the web console (type Ctrl-Maj-K)
3. In the web console, type "bug()", and validate
Actual Results:  
Loads chrome://browser/content/browser.xul in the main page.

Expected Results:  
Loading http://ophir.lojkine.free.fr/bug.html#

Comment 6

[David Dahl :ddahl]

Hmm. another strange thing about this is this error when running "bug":

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: chrome://browser/content/browser.js :: prepareForStartup :: line 6715"  data: no]

Comment 7

[David Dahl :ddahl]

Blake, Gavin:

this is a weird one since we are changing the location in a sandbox. Do you guys know what is happening here? window.location = "" or window.location = "#" will load browser.xul

Comment 8

[Rob Campbell [:rc] (:robcee)]

even loading about:blank, opening a console and entering window.location = "#" causes this to happen.

nominating for blocking final.

Comment 9

[Kevin Dangoor]

I agree that we need to get this fixed. On the other hand, I personally would not hold the release of Firefox 4 on this.

Thanks for the test case @pere.jobs...

Comment 10

[Ophir LOJKINE]

I am very happy to have contributed to such a large project! It's the beauty of free software...

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking, but we need to get an sg:eval on this.

Comment 12

[Johnathan Nightingale [:johnath]]

And would like to approve a safe patch.

Comment 13

[Kevin Dangoor]

We just investigated this a bit more. This only happens from the Web Console's terminal, not from normal script execution.

Comment 14

[Ophir LOJKINE]

(In reply to comment #13)
> This only happens from the Web Console's
> terminal, not from normal script execution.

That's why I wrote „when using the Web Console” in the title of the bug... :)

Comment 15

[Ophir LOJKINE]

Hey! Did you forget this bug? I would really like it to be corrected...

Comment 16

[Kevin Dangoor]

Hey,

Not forgotten, but this hasn't yet risen to the top of our queue unfortunately. This bug hits a corner case and there are still some common cases that we're trying to improve.

One thing I just noticed in the original report is that you're doing this:

window.location="#Something"

is the behavior any different if you do this:

window.location.hash="#Something"

?

Thanks for the ping.

Comment 17

[Ophir LOJKINE]

I just tried window.location.hash="#Something" , and there is no problem with that.

Note: resolving bug #626993 would also resolve this bug, I imagine...

Comment 18

[Rob Campbell [:rc] (:robcee)]

(In reply to comment #17)
> I just tried window.location.hash="#Something" , and there is no problem
> with that.
> 
> Note: resolving bug #626993 would also resolve this bug, I imagine...

Yes, but as I commented there, there are valid reasons for wanting to load browser.xul into content. Just not via this side-effect. :)

Thanks for sticking with this. As Kevin suggests, it's on our radar.

Comment 19

[Rob Campbell [:rc] (:robcee)]

This seems to have been fixed. Found during triage.