Closed Bug 70682 Opened 24 years ago Closed 22 years ago

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

Categories

(SeaMonkey :: Location Bar, defect, P3)

Product:
SeaMonkey
Component:
Location Bar
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 63334
Milestone:
mozilla1.1alpha

People

(Reporter: johann.petrak, Assigned: jag+mozilla)

References

Details

(Keywords: perf)

Attachments

(3 files)

[patch] possible fix
617 bytes, patch
Details | Diff | Splinter Review
[patch] updated patch
729 bytes, patch
Details | Diff | Splinter Review
[patch] Updated patch, including startPage -> pageToLoad
1.87 KB, patch
Details | Diff | Splinter Review 
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
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.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: smoketest
OS: Linux → All
urlbar?
Assignee: asa → alecf
Component: Browser-General → URL Bar
QA Contact: doronr → claudius
Severity: critical → blocker
this is a smoketest blocker
no, it's not.
Severity: blocker → normal
Keywords: smoketest
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? 
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.
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.
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
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.
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 :)
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9
Depends on: 68720
*** Bug 71580 has been marked as a duplicate of this bug. ***
*** Bug 71580 has been marked as a duplicate of this bug. ***
*** Bug 71580 has been marked as a duplicate of this bug. ***
*** Bug 71580 has been marked as a duplicate of this bug. ***
*** Bug 71580 has been marked as a duplicate of this bug. ***
*** Bug 71580 has been marked as a duplicate of this bug. ***
Keywords: perf
*** Bug 48524 has been marked as a duplicate of this bug. ***
*** Bug 73391 has been marked as a duplicate of this bug. ***
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
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).
Oh, OK then :-) The variable name confused me. Changing it might be good, I 
guess :-) Sorry...

Gerv
Assignee: alecf → disttsc
Status: ASSIGNED → NEW
even initialPage would probably work as long as it isn't 'startPage' which is 
as Gerv said.
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...
r=mao
Fix checked in, marking fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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).

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

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

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?

was any bug filed on the remaining issue here? bug 124231 was just filed.
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.
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.
Verified on 2002020421.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The Target Milestone (0.9) is long passed.  This bug should be retargeted.
Nominating for Mozilla 1.1 (supposing there's no time for 1.0 now). Complaints
in the original report are still valid and important.
Keywords: mozilla1.1
-> 1.1
Target Milestone: mozilla0.9 → mozilla1.1
and -> other e-mail addy
Assignee: jag → jaggernaut
Status: REOPENED → NEW
Isn't this a dupe of bug 63334 (already fixed)?

The problem johann@ai.univie.ac.at mentions in comment 38 is bug 95897 (a wontfix).
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.
johann@ai.univie.ac.at: See bug 95897 comment 9. Your comment belongs in that
bug anyway.
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.
> 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 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → DUPLICATE
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: