70682 - When opening a link in new window, the URL is not filled before the page is starting to load

Status: RESOLVED DUPLICATE of bug 63334

(SeaMonkey :: Location Bar, defect, P3)

Description

[[e-mail]]

From Bugzilla Helper:
User-Agent: Mozilla/4.5 [en] (X11; I; SunOS 5.6 sun4u)
BuildID:    2001022808, ALL?

I believe this is the same with all OS, but didnt try.

When A new browser window opens after using the "open link
in new window" option, no url is filled into the location
bar. So when a timeout or other problem occurs, its no
use to press reload and impossible to try again.
Often, the page with the original link in the other window 
will long be lost in the meantime.
Not sure if this is a bug or request for enhancement, but
I prefer to see it as a bug (after all the functionality of
open in other window is expected to be: open window, fill in
URL, press go)

Reproducible: Always
Steps to Reproduce:
n/a

Comment 1

[Håkan Waara]

I can confirm this on a trunkbuild from an hour ago.

For me it doesn't even *go* to the location, so all that is left is a blank 
window with no content and no URL!

Is this a smoketest blocker?  Severity->Critical, OS->All, adding smoketest 
keyword. Please remove if this is unappropriate.

I have no idea to which component this should go.

Comment 2

[timeless]

urlbar?

Comment 3

[Håkan Waara]

this is a smoketest blocker

Comment 4

[Alec Flett]

no, it's not.

Comment 5

[Chase Tingley]

Odd.. I don't see this in 2001030110 on Win98, even though it was reported in
022808 build and hwaara says its in trunk. Could this be a platform issue? 

Comment 6

[Håkan Waara]

Ugh.. I'm repulling and rebuilding now to see if my bug still exists. It 
doesn't belong to this bugreport anyway, so hereby I undo all my comments and 
changes to this bug.

Sorry for the inconvenience.

Comment 7

[Peter "jag" Annema]

Attachment: [patch] possible fix

Comment 8

[Peter "jag" Annema]

I don't have a current tree nor the time to test this right now, but this should
set the url-to-be-loaded in the urlbar when a new window is opened (e.g. at
startup and from open link in new window), and not affect any of the other
cases.

Comment 9

[Boris Zbarsky [:bzbarsky]]

I just tried that patch and it works great for me.  The one issue is that if you
have Mozilla set to a blank home page, it will put "about:blank" in the urlbar
briefly when you hit Ctrl-N before clearing the URL bar....

Also, this patch fixes the old and really annoying bug 48524

Comment 10

[Peter "jag" Annema]

The fix for not placing about:blank in there is:

-    if (startPage)
+    if (startPage && startPage != "about:blank") {
+      gURLBar.value = startPage;
       loadURI(startPage);
+    }

This will also prevent us from trying to load about:blank (again), though I
think the loadURI code would also have caught that.

Comment 11

[Alec Flett]

this is cool - if jag can't test now, we need more testing before we can land
this, especially as it's on the critical path to opening a window :)

Comment 12

[Peter "jag" Annema]

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

Comment 13

[Peter "jag" Annema]

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

Comment 14

[Dave Miller [:justdave]]

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

Comment 15

[Peter "jag" Annema]

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

Comment 16

[timeless]

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

Comment 17

[Keyser Sose]

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

Comment 18

[Peter "jag" Annema]

Attachment: [patch] updated patch

Comment 19

[Boris Zbarsky [:bzbarsky]]

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

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

Comment 21

[Gervase Markham [:gerv]]

Whoa, there - surely this patch fixes an entirely different problem to this bug?

The bug is that, (AIUI) if you do "Open In New Window" at www.foo.com, and 
www.foo.com times out, the URL bar does not say www.foo.com - it is, instead, 
empty. The reporter would like it to say www.foo.com so he can press Enter in 
the URL bar to retry.

The patch attached to this bug does not leave it blank, but instead loads the 
start page URL, which is not what's wanted.

Or have I got it wrong?

Gerv

Comment 22

[Peter "jag" Annema]

Where startPage is the page the window starts with (perhaps I should've called
it pageToLoad?), so if you open a link in a new window, it is passed to the new
window through arguments[0], which gets placed in the startPage variable, and
then loaded (and placed in the urlbar, with this patch).

Comment 23

[Gervase Markham [:gerv]]

Oh, OK then :-) The variable name confused me. Changing it might be good, I 
guess :-) Sorry...

Gerv

Comment 24

[timeless]

even initialPage would probably work as long as it isn't 'startPage' which is 
as Gerv said.

Comment 25

[Peter "jag" Annema]

Attachment: [patch] Updated patch, including startPage -> pageToLoad

Comment 26

[Peter "jag" Annema]

The interesting part of that patch is this change (paraphrased, not literal
quote from the patch):

     if (pageToLoad && pageToLoad != "about:blank")
     {
+      gURLBar.value = pageToLoad;
       loadURI(pageToLoad);
     }

This places the url of the page to load when a window is opened in the url bar.
The rest of the patch is merely a change from startPage to pageToLoad, though
I'm now considering uriToLoad...

Comment 27

[Ben Goodger (use ben at mozilla dot org for email)]

sr=[e-mail]

Comment 28

[Mark Olson]

r=mao

Comment 29

[Peter "jag" Annema]

Fix checked in, marking fixed.

Comment 30

[Daniel Bratell]

What happens if you click on a link and it isn't in DNS? Will the urlbar display
the new or old url?

Displaying the new would be confusing (and plain wrong).

Comment 31

[Peter "jag" Annema]

Any link click which doesn't open a new window won't go through this code path,
and won't be affected by this patch.

When a new browser window opens, you always start with a blank page and an empty
location bar. If the browser was instructed to load an URI, it will load the
URI, and when the page is successfully being loaded, update its notion of the
"current" location, which results in the URI being put in the location bar. With
the patch in this bug applied, when a new browser is opened and instructed to
load an URI, it will immediately put the URI in the location bar so that if
something goes wrong, you at least have the URI of the page you wanted to load
in the location bar. This makes it easier to try to load the page for a second
time, e.g. after you've restored your network connection, yelled at your ISP to
fix their DNS, or whatever.

So what could happen is that you get redirected, but when that happens, the URI
it first put there will be overwritten by the "redirected URI".

I hope this addresses your concerns, if not, please let me know.

Comment 32

[Nikos Platis]

I find the way this feature works a little unsatisfactory: Try opening a URL in
a new window and hit Stop before the page loads (or get a timeout!). The URL is
filled in the location bar, so clicking in the location bar and hitting Return
makes Mozilla try to load the page again. But try hitting Reload and the URL
disappears from the location bar! This may well be the "correct" behavior for
the Reload button (no page is loaded at that time) but it is logical to assume
that hitting Reload will try to load the page appearing in the location bar. I
believe this is the way NS4 worked.

Comment 33

[dylang]

There's a sick new twist to this story.

You see, if I open a link in a new window, the location bar is populated.

BUT if it can't display a page (and I click the dialog away for "can't load
this"), then hit reload .. 

THE LOCATION BAR IS BLANKED AND THE RELOAD FAILS!

Agh ... please fix this :p

Steps to reproduce:
1) Right click, open in new window a link to a site with a problem like no DNS entry
2) Wait for the browser to timeout and clear the dialog ("The operation
attempted timed out" [ok])
3) Click the reload button

Comment 34

[Peter "jag" Annema]

Yeah, that makes sense. The page didn't actually load, so a reload will not
cause that page to be reloaded, but the last page (in this case, the blank
page).

We could keep track of whether the page was loaded or not, then make Reload use
that information for which page to (re)load. I wonder if there's a more elegant
solution though.

cc'ing a few people.

Comment 35

[dylang]

Situation 1: page loaded succesfully.  Clicking reload causes the app to regrab
the page (perhaps bypassing cache)

Situation 2: page did not load succesfully.  Clicking reload causes the app to
retry the connection.

In both cases the overall behaviour has changed such that any previous good
loads are in the history; reloading would only affect the most recent URL
entered and attempted to load (wether it worked or not).

This can be handy when you are trying to load a site which may be experiencing
temporary problems (/.ed, kuroded, etc).

Comment 36

[dylang]

Related to this:
  Location bar not populated before load from bookmark.
  Location bar not populated before load from history.

Separate bugs?  Or can this one be used?

Comment 37

[R.K.Aa.]

was any bug filed on the remaining issue here? bug 124231 was just filed.

Comment 38

[[e-mail]]

I am experiencing what seems to be a regression with 0.9.8 (2002020415/linux).
When I click on a link and select "open in new window" from the context
menu and then press the reload button before the page in the new window
started to load, the url that has appeared in the location bar disappears.
Now this is very disturbing when the server for the new page is slow -- if I 
relead in an attempt to make a new connection, the URL disappears.

Comment 39

[[e-mail]]

BTW with some luck you should be able to reproduce this by opening a
link in a new window, then *quickly* klick the stop button, then klick 
the reload button. If the page didnt load before the stop button was pressed
(view source will show a bogus empty page in that case), the reload button
will clear the location bar.

Comment 40

[dylang]

Verified on 2002020421.

Comment 41

[Fuzzy Gorilla]

The Target Milestone (0.9) is long passed.  This bug should be retargeted.

Comment 42

[Dimitrios]

Nominating for Mozilla 1.1 (supposing there's no time for 1.0 now). Complaints
in the original report are still valid and important.

Comment 43

[jag (Peter Annema)]

-> 1.1

Comment 44

[jag (Peter Annema)]

and -> other e-mail addy

Comment 45

[Jonas Jørgensen]

Isn't this a dupe of bug 63334 (already fixed)?

The problem [e-mail] mentions in comment 38 is bug 95897 (a wontfix).

Comment 46

[[e-mail]]

Excuse me, deciding not to fix the reload problem for unsuccessful open attempts
is just silly and one more example of doing the wrong thing from a user interface
perspective: if I try to load a page and it fails there is nothing more
natural than to attempt to do it again (especially since in many cases it
will succeed).
Even IE is able to do this correctly, and as far as I remember NS4 was too.

Comment 47

[Jonas Jørgensen]

[e-mail]: See bug 95897 comment 9. Your comment belongs in that
bug anyway.

Comment 48

[Santos]

Build 2002033109, windows xp. I open a non working link in a new window, in the
window, the URL is there but clicking Reload does nothing, clicking the GO
button, makes the browser try again. Same action but on a new tab, the URL isn't
there, nothing can be done, unless, obviously,  trying to open again the link
from the origin page. Please fix this bug for 1.0.

Comment 49

[Jonas Jørgensen]

> I open a non working link in a new window, in the
> window, the URL is there

Which means that this bug is fixed.

> but clicking Reload does nothing,

That has nothing to do with this bug. See bug 95897.

> Same action but on a new tab, the URL isn't
> there, nothing can be done

That has nothing to do with this bug. See bug 103720.

> Please fix this bug for 1.0.

This bug is a duplicate of 63334 which _is_ _already_ _fixed_!


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