128936 - Setting document.location does not load new page

Status: RESOLVED DUPLICATE of bug 122866

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

Description

[Frank Burleigh]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.8+)
Gecko/20020303
BuildID:    2002030308

Setting document.location in javascript changes the URL bar but does not load
the new page (at this site).

Reproducible: Always
Steps to Reproduce:
1. visit the site, pretend like you're buying a Thinkpad by choosing a
processor, an OS and an application suite.
2. click the Customize button graphic at page bottom
3. observe the URL bar.  Now push the Refresh button or simply enter the URL bar
and press the return key.

Actual Results:  A blank page.

Expected Results:  Move to the page for the URL.

This might be related to bug 110939 but this one may be more direct than that
bug, which has become wound up in form submission.  I don't think this bug is
about form submission (and maybe neither is that bug), since IBM's form is only
meant to gather up some information, which they then parse in JS, building a
URL.  They then set document.location to that URL--they never actually submit
the form.  The URL bar changes but the page does not actually change--we go blank.

Comment 1

[Sivakiran Tummala]

I clicked on the continue button (could not find the customize button at the 
URL). The page loaded properly with the 03/01 build on WinXP.
Anyway this is not a dom core problem, over to dom level 0 

Comment 2

[Frank Burleigh]

Yes, the button is Continue--sorry.  I've checked NS6.21 from my home XP machine
with 56k modem and did not experience this problem.  I will check it again with
tomorrow's moz win32 trunk nightly.

Comment 3

[Prashant Desale]

Resolving this as Worksforme. Reporter does not see this problem anymore either.
Please Re-open if problem arises again.

Comment 4

[Frank Burleigh]

Perhaps my earlier comment was unclear: *NETSCAPE* 6.21, on my home XP machine,
does not show this problem.  *MOZILLA* build 2002030604 on my work XP machine
*does* show this problem, including after an uninstall and complete reinstall. I
assume you are using the same nightly trunk build on a similar platform, so I'm
perplexed about what to do next other than to say "I'm not kidding." ;-)

Comment 5

[Boris Zbarsky [:bzbarsky]]

I can't reproduce this on linux build 2002-03-08-07.  Frank, do you have any of
the "Allow web pages to..." preferences turned off in "Scripts & Windows"
prefs?  Are there any errors in the JS console when you click that button?

Comment 6

[Frank Burleigh]

I did have "Open unrequested windows" off but thought that would not apply to
this scenario since the JS isn't asking to open a new window, but to change the
location of the current one.  Still, I've just turned *on* that setting; all
others *except* "move or resize existing windows..." are also on.  I exited then
restarted Moz (2002030803), tried my test, and got the same result: the URL
changes but the browser window has gone blank--no content.  My linux machine is
off with no video so I can't test there for a few weeks.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Could you try enabling "move or resize existing windows" as well?  Just to make
sure that's not doing it?

Comment 8

[Frank Burleigh]

Excellent hunch, Boris!  With that ON the page loads ok (though not if you
change the setting to ON, then BACK then test).  I tested turning move/resize
OFF and again got a blank result.

In either case, the url's contents do change--the load just doesn't happen
unless Move/Resize is ON.

To me, that's wrong behavior unless the wording is changed to be Move/Resize or
Change Content.

Thanks, Boris.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Well... the URL that is loading has:

 function loadPage() 
  {  
   if(navigator.appName.indexOf(NETSCAPE_BROWSER_NAME) != -1)
     {
       // do some stuff
        window.resizeBy(-1, -1);
     }
  }

At the moment, all the content controls in the Scripts & Windows section stop
code execution with a security violation exception when the page attempts the
action in question.  So this page calls loadPage() and execution stops there.
Unfortunately, the page author was very clever and the page in question is a
frameset with no src attributes on the frames.  The attributes are set in the
loadPage() function after this resizing business (yes, this means the site is
not usable by someone who has JS disabled or just happens to be blind and using
a text browser).  Hence no loading of content.

Duplicate of "Annoying-content controls should not stop script execution"

*** This bug has been marked as a duplicate of 122866 ***