545314 - iframe.location.assign broken in FF 3.6

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Dennis Haney]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; da; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; da; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)

iframe.location.assign("page.aspx") : not work, used to work in FF 3.5

iframe.location.assign("http://localhost/page.aspx") : work


Reproducible: Always

Steps to Reproduce:
1. see above
2.
3.
Actual Results:  
works as in FF 3.5

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

*minimal* testcase added using 'Add an attachment' would be great.

and need to find the regression range.

Comment 2

[Mats Palmgren (inactive)]

Attachment: Testcase

Regression range:  2009-06-20-03 -- 2009-06-21-03
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=794b04051344&tochange=a8daae5ef5ce

In 2009-06-21-03, Error Console says:

Error: uncaught exception: [Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIDOMLocation.assign]"  nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)"  location: "JS frame :: http://localhost/test/545314.html :: <TOP_LEVEL> :: line 1"  data: no]

Comment 3

[Peter Van der Beken [:peterv]]

We somehow have a null uri in the docshell. If the regression range is right then this could be fallout from bug 484764, but I have no idea how that could happen.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

This bug is awesome. I went back to my 1.9.1 build and found that the reason that the docshell has a content viewer on that branch is because of this partial stack:

#0  nsDocShell::SetCurrentURI (this=0x7fffd6ea4400, aURI=0x7fffd4fa46b0, aRequest=0x0, aFireOnLocationChange=1)
    at /home/mrbkap/work/1.9.1/mozilla/docshell/base/nsDocShell.cpp:1277
#1  0x00007fffe235a2f3 in nsDocShell::CreateAboutBlankContentViewer (this=0x7fffd6ea4400, aPrincipal=0x7fffd4fa4080, 
    aBaseURI=0x7fffd59b6a20) at /home/mrbkap/work/1.9.1/mozilla/docshell/base/nsDocShell.cpp:5537
#2  0x00007fffe2359c75 in nsDocShell::EnsureContentViewer (this=0x7fffd6ea4400)
    at /home/mrbkap/work/1.9.1/mozilla/docshell/base/nsDocShell.cpp:5433
#3  0x00007fffe2346e54 in nsDocShell::GetInterface (this=0x7fffd6ea4400, aIID=..., aSink=0x7fffffffa658)
    at /home/mrbkap/work/1.9.1/mozilla/docshell/base/nsDocShell.cpp:469
...
#10 0x00007fffe32127a6 in nsGlobalWindow::EnsureInnerWindowInternal (this=0x7fffdbedec00)
    at /home/mrbkap/work/1.9.1/mozilla/dom/src/base/nsGlobalWindow.h:406
#11 0x00007fffe31ff984 in nsWindowSH::NewResolve (this=0x7fffde9d09d0, wrapper=0x7fffd4f8ac80, cx=0x7fffde80cc00, 
    obj=0x7fffd4fb6a40, id=140736883323060, flags=16, objp=0x7fffffffaae0, _retval=0x7fffffffab18)
    at /home/mrbkap/work/1.9.1/mozilla/dom/src/base/nsDOMClassInfo.cpp:5979
#12 0x00007fffe8ab77bc in XPC_WN_Helper_NewResolve (cx=0x7fffde80cc00, obj=0x7fffd4fb6a40, idval=140736883323060, 
    flags=16, objp=0x7ffffffface0)
...
#15 0x00007ffff75ffa6e in JS_LookupPropertyWithFlags (cx=0x7fffde80cc00, obj=0x7fffd4fb6a40, 
    name=0x7fffe3649942 "Location", flags=16, vp=0x7fffffffae30)
    at /home/mrbkap/work/1.9.1/mozilla/js/src/jsapi.cpp:3497
#16 0x00007fffe31f8ae1 in nsDOMClassInfo::PostCreate (this=0x7fffdbedd760, wrapper=0x7fffd4f8af20, cx=0x7fffde80cc00, 
    obj=0x7fffd4fb6dc0) at /home/mrbkap/work/1.9.1/mozilla/dom/src/base/nsDOMClassInfo.cpp:3916
...
#20 0x00007fffe31f1815 in nsDOMClassInfo::WrapNative (cx=0x7fffde80cc00, scope=0x7fffd4fb6a40, native=0x7fffd4fbb7c0, 
    aIID=0x7fffe3647a60, vp=0x7fffffffb4d0, aHolder=0x7fffffffb490)
    at /home/mrbkap/work/1.9.1/mozilla/dom/src/base/nsDOMClassInfo.cpp:1670
#21 0x00007fffe32008c4 in nsWindowSH::NewResolve (this=0x7fffde9d09d0, wrapper=0x7fffd4f8ac80, cx=0x7fffde80cc00, 
    obj=0x7fffd4fb6a40, id=140737105458788, flags=1, objp=0x7fffffffb790, _retval=0x7fffffffb7c8)
    at /home/mrbkap/work/1.9.1/mozilla/dom/src/base/nsDOMClassInfo.cpp:6298

that is: we're wrapping 'location' and in PostCreate, in order to set up the Location constructor object, we resolve it, which forces an inner window to be created, which, in turn, causes us to create a transient about:blank content viewer. Now, because PostCreateProto doesn't actually have to do a lookup, we don't manage to create a temporary content viewer and the location object that we return isn't useful until we return to the event loop and the actual load of about:blank (in this case) starts.

Note that 'location' is a special object here: we explicitly don't forward to the inner object. I'll attach a proposed fix in a second.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Proposed fix

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Since this regression is on the 1.9.2 branch, we should fix this there, too.

Comment 7

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

We'll take it on mozilla 1.9.2 once this has landed and baked on mozilla-central. Also, we'll want a test in that patch.

Comment 8

[Daniel Veditz [:dveditz]]

Where are we with this regression fix? It has had a patch for a while, but no trunk check-in.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/mozilla-central/rev/62d08a22f394 -- there's another bug that subsumes this patch, but its patch breaks some focus mochitests, so I'm getting this in until I have time to fix that one everywhere.

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/mozilla-central/rev/f2a94c5a8e0a to fix bustage.

Comment 11

[Daniel Veditz [:dveditz]]

We'd still consider this for 1.9.2, but would need a roll-up patch that includes the bustage fix.