Last Comment Bug 231393 - Tab URL does not persist on bad links if tabs switched
: Tab URL does not persist on bad links if tabs switched
Status: RESOLVED WORKSFORME
: dataloss, polish
Product: Firefox
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: unspecified
: x86 All
: P4 major with 72 votes (vote)
: Firefox1.5
Assigned To: Yoni Gilad
:
Mentors:
: 211879 229057 233891 234885 235378 236625 239245 240517 241801 246903 247061 247808 250990 253976 256143 259026 268915 274804 278602 280961 285857 289064 290130 296634 297053 298040 303668 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-18 14:24 PST by Steve Wardell
Modified: 2009-09-18 13:20 PDT (History)
70 users (show)
mconnor: blocking0.8-
mconnor: blocking0.9-
chofmann: blocking‑aviary1.0-
dbaron: blocking‑aviary1.0.3-
mconnor: blocking‑aviary1.5-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Port of patch from seamonkey bug (original patch by jag) (12.59 KB, patch)
2004-04-27 05:45 PDT, PikeUK
mconnor: review+
Details | Diff | Splinter Review
patch checked in to aviary (10.70 KB, patch)
2004-07-23 17:23 PDT, Mike Connor [:mconnor]
no flags Details | Diff | Splinter Review
patch (2.40 KB, patch)
2005-03-31 20:06 PST, Yoni Gilad
no flags Details | Diff | Splinter Review
better patch (5.58 KB, patch)
2005-04-01 04:46 PST, Yoni Gilad
mconnor: review+
Details | Diff | Splinter Review
Failed Patch Attempt (6.12 KB, application/octet-stream)
2005-05-15 01:50 PDT, Aniruddha Shankar
no flags Details
Failed Patch Attempt (6.12 KB, application/octet-stream)
2005-05-15 01:50 PDT, Aniruddha Shankar
no flags Details
Failed Patch Attempt (6.12 KB, application/octet-stream)
2005-05-15 01:51 PDT, Aniruddha Shankar
no flags Details

Description Steve Wardell 2004-01-18 14:24:58 PST
1) Open a new tab
2) enter a bad URL (e.g. www.fdfdfdfdfdf.com) \
3) press enter to submit
4) Warning pops
5) Switch to a different tab, then switch back.

Expected Result (and how Seamonkey works): The bad URL is still shown in URL bar 

Actual Result: URL bar is blank

This is the Firebird version of Bug 103720 (Seamonkey). It seemed like Bug
204103 was opened to be it's companion but it was closed before this was fully
addressed.
Comment 1 Steve Wardell 2004-01-18 14:26:23 PST
Requesting blocking. This could be considered a dataloss situation and was
addressed in Seamonkey in Bug 103720.
Comment 2 José Jeria 2004-01-18 14:38:15 PST
Bug mentioned in comment 0 was wrong, should be bug 203102.
Comment 3 Steve Wardell 2004-01-18 14:41:03 PST
Thanks, you're correct.
Comment 4 Brian Earley 2004-01-18 17:28:44 PST
_This_ is a blocking0.8? bug? This is far from severe enough to block 0.8.

The URL bar is not blank for me, it's "about:blank".
Comment 5 Mike Connor [:mconnor] 2004-01-19 00:07:48 PST
this isn't a grandma-killing bug.
Comment 6 Ben Ruppel 2004-01-19 07:50:36 PST
Perhaps, but it is such a pain in the butt.  You've never opened a bunch of
links in tabs only to find out later that one of them didn't load and you've got
to go back and play detective to figure out which one it was?  Perhaps this
shouldn't be a blocker, but darn, this bug needs attention. 
Comment 7 Florian Effenberger 2004-01-19 10:42:26 PST
Full ACK! This one really sucks ;)
Comment 8 PikeUK 2004-01-22 05:17:42 PST
The minimal level changes to get this working is to change the relevant part of
addTab in tabbrowser.xml to something like this (this WFM anyway) as discussed
in Bug 103720.

if (!blank) {
  b.loadURIWithFlags(aURI, nsIWebNavigation.LOAD_FLAGS_NONE,
                     aReferrerURI, null, null);
  b.userTypedValue = aURI;
}

However even better would be to port the second patch ("Also remember what the
user tried to load, v1.2") from Bug 104778 which includes this fix and some
others, is anyone working on porting that patch or do we only want these
specific changes?
Comment 9 James Brown 2004-01-27 12:18:22 PST
This bug could be extended with the following:

When right-clicking on an URL which is not valid, and selecting "Open Link in
New Tab", the new tab is opened, an error message box is displayed, and after it
is closed the URL is lost. The text in the error message box includes the
domain, but it is not obvious to which tab it is related, since tabs open in the
background. Maybe this whole thing should be reconsidered
Comment 10 Ben Ruppel 2004-01-27 13:14:04 PST
There is a bug to replace that error dialog box with an error page (like IE does).
bug 28586 
Don't know if Firebird would adopt this automatically.  Haven't seen much
progress on this bug lately.
Comment 11 Jeff Walden [:Waldo] (remove +bmo to email) 2004-01-27 13:54:19 PST
(In reply to comment #10)
> There is a bug to replace that error dialog box with an error page (like IE
> does).
> bug 28586 
> Don't know if Firebird would adopt this automatically.  Haven't seen much
> progress on this bug lately.

That's more for Mozilla than for Mozilla Firebird.  See Ben's bug 216466 for
details.  There are a few bugs that need work before a change should be made,
tho, so don't expect it for a bit.

Comment 12 Mike Connor [:mconnor] 2004-01-27 14:02:18 PST
there's a Firebird bug to use XUL error pages already.  Hopefully this is 
practical before 1.0

There's also an extension to show the failed URL when the existing pref is 
used, which I use currently, and other than a weirdness with history entries, 
its great.
Comment 13 bugzilla2005 2004-02-09 12:03:42 PST
*** Bug 211879 has been marked as a duplicate of this bug. ***
Comment 14 bugzilla2005 2004-02-09 12:14:58 PST
Bug 211879 is probably the same issue, so it's duped here, but to prevent some
stupid workaround that fixes the symptoms of this bug, and not the symptoms of
that one (instead of fixing the bug itself), be accepted as a resolution, I copy
the description from #211879 here.  (Such 'resolutions' are not without
precedent, see bug 203102 for instance.)

The only difference in this recipe is that the URL is opened by clicking on a
link, and it does not have to be "bad", it might just take a long time for
loading to start, but the URL should be displayed even in this (pre-loading) phase.


When opening a link in a new tab (and possibly window, haven't checked that),
the location bar in the new tab does not get filled in until page rendering is
started.  This way, there is a possibly long phase during loading, when the user
has no information in the tab about what URL is being loaded.  When page loading
fails (without a server-side error page, e.g dns or network error), or the user
chooses to cancel loading (possibly because he wants to try again later), the
URL is lost, and `about:blank' is displayed instead, making it much more
difficult to try again loading the page later.

A common usage pattern when this bug is really annoying, is when you are reading
a page and opening lots of links in the background in new tabs, for reading them
after you have finished with the current one.  When iterating over the new tabs,
if some of them failed to load, you have no idea what URL it was, and cannot try
 reloading it.  

Mozilla 1.4 does not have this bug, i.e. it fills the location bar before
starting to load the page.

See also non-Firebird bug 191145.

Reproducible: Always

Steps to Reproduce:
Open an unreachable URL in a new tab.
Comment 15 José Jeria 2004-02-11 11:25:32 PST
*** Bug 233891 has been marked as a duplicate of this bug. ***
Comment 16 Aniruddha Shankar 2004-02-15 02:30:56 PST
Bug still persists with Firefox 0.8 and with nightly build of 15th February 2004
Comment 17 José Jeria 2004-02-19 14:59:17 PST
*** Bug 234885 has been marked as a duplicate of this bug. ***
Comment 18 José Jeria 2004-02-24 02:00:08 PST
*** Bug 235378 has been marked as a duplicate of this bug. ***
Comment 19 Bill Mason 2004-03-05 16:53:20 PST
*** Bug 236625 has been marked as a duplicate of this bug. ***
Comment 20 Daniel Varga 2004-03-06 17:18:22 PST
(In reply to comment #5)
> this isn't a grandma-killing bug.

This bug causes data loss, and major inconveniences. If this isn't a
grandma-killing bug, I don't know what is. As a heavy Firebird user, I encounter
the very annoying "lost link" phenomenon almost hourly.
Comment 21 Bill Mason 2004-03-30 21:37:05 PST
*** Bug 239245 has been marked as a duplicate of this bug. ***
Comment 22 Alexey Molchanov 2004-04-02 14:15:19 PST
I totally agree with comment #20 by Daniel Varga.
This is the _most_ annoying bug in FF (at least for me). Try to open new 10-20
tabs on bad dial-up connection and when your connection broke you'll end up with
all this tabs with empty address bar. It's f*cking annoying! All my friends who
recently switched to Firefox complain about this bug too.
Comment 23 Bradley Chapman (not reading bugmail, still gone but not forever) 2004-04-04 14:50:05 PDT
(In reply to comment #20)
> (In reply to comment #5)
> > this isn't a grandma-killing bug.
> 
> This bug causes data loss, and major inconveniences. If this isn't a
> grandma-killing bug, I don't know what is. As a heavy Firebird user, I encounter
> the very annoying "lost link" phenomenon almost hourly.

Agreed. It's one of those cosmetic things that greatly enhances usability.
blocking0.9? indeed.
Comment 24 Greg Campbell 2004-04-04 19:41:37 PDT
(In reply to comment #12)
> there's a Firebird bug to use XUL error pages already.  [...]
> There's also an extension to show the failed URL when the existing pref is 
> used, [but it has] a weirdness with history entries

The Show Failed URL extension's functionality (along with XUL error pages)
should happen before 1.0. I use it and it's fine and dandy. The history
weirdness (bug 226401) is less critical than this bug, IMHO. Admittedly, I
disagree with the target on bug 216466 ("after 1.0"); I think the whole error
page thing, especially the issue in this bug, should be relatively polished for 1.0.
Comment 25 David Balažic 2004-04-10 05:17:08 PDT
If this problem were minor, people wouldn't report is so often ( go count the
duplicates/comments) :rolleyes:
Comment 26 project5 2004-04-15 06:01:22 PDT
This bug seems trivial to solve and is enormously annoying. As others have said,
opening links in the background can lead to several tabs displaying no URL. If
the page where the links were opened from is gone (e.g. a result from a google
search which contained some links), you've got to go and first find that
original page, then track down which of the links you tried to open, failed to
and then re-open them. This happens to me on a regular basis - I'm very careful
nowadays to not close pages before everything has opened, but even that is not
ok because one still needs to play detective to find out which of the links
exactly failed to load.

Of all the things I'd like to see added to or fixed in FireFox, this is by far
the one I consider most important.
Comment 27 Daniel Varga 2004-04-15 06:48:48 PDT
(In reply to comment #26)

"Of all the things I'd like to see added to or fixed in FireFox, this is by far
the one I consider most important."

Now someone please tell me where to go with my big "please please fix bug
#231393" banners. Because talking about it on this page doesn't seem to help.
What's the most effective way to let the developers know how many people want
this bug fixed?
Comment 28 Mike Connor [:mconnor] 2004-04-15 07:59:34 PDT
there's underlying issues that have prevented this from being fixed thus far, 
not trivial whatsoever to fix the "right" way,  however I anticipate this will 
be resolved before 1.0.

Please keep in mind the current priorities from a development/testing 
perspective is to make 0.9 "feature-complete" meaning that all of the major 
features targeted for 1.0 will be done and active.  This means that plain old 
fixing bugs is secondary to getting that done.  The plan is to have 0.9 pretty 
much the finished product, then harden and polish the product on the stable 
branch.

Setting blocking flags inappropriately will only get your bugzilla privileges 
removed, btw.
Comment 29 Mike Connor [:mconnor] 2004-04-15 21:05:28 PDT
*** Bug 240517 has been marked as a duplicate of this bug. ***
Comment 30 Michel Meyers 2004-04-15 23:38:47 PDT
(In reply to comment #27)
> What's the most effective way to let the developers know how many people want
> this bug fixed?

Just vote for it (that's what Bugzilla's voting system is for) and be patient
(from what I hear/read this bug isn't all that easy to fix but I guess it will
be 'blocking 1.0' if enough people register their votes).
Comment 31 David Balažic 2004-04-16 00:21:50 PDT
Re Comment #28 :

So the plan is to push in as much garbage as possible and pretend that it is
possible to fix it all later ?
Will it take 2 years between 0.9 and 1.0 ?
Or will the majority of bugs still be there in v1.8 ( just like it is now in
mozilla ? )

Rant off ...
Comment 32 Mike Connor [:mconnor] 2004-04-24 17:44:42 PDT
pike, re comment 8, can you port the relevant portions and post a patch here? 
This would be nice to have for 0.9, and a must-have for 1.0beta

minusing blocking0.9?, however we'll take a patch if there is one in time.

before anyone rants on this, please keep the roadmap in mind.  This can be fixed
before 1.0, and will be, but 0.9 is still just a step in the road.

taking provisonally so that this stays on my radar.  Pike, if you can post a
patch, please take the bug :)
Comment 33 PikeUK 2004-04-25 13:04:05 PDT
(In reply to comment #32)
> pike, re comment 8, can you port the relevant portions and post a patch here? 
> This would be nice to have for 0.9, and a must-have for 1.0beta

I attempted to port the patch a short while after I posted that comment but ran
into some difficulties (if I remember right I think it revolved around the
progress listener being called twice each time a tab was switched and the second
call was removing the stuff from the first call). I'll dig out my WIP patch and
see if I can resolve the issues I had with it sometime later this week (I won't
accept the bug because I don't know yet whether I can get it to work, if someone
with a clue is working on this I don't want my playing around to put them off
fixing it :-).
Comment 34 Bradley Chapman (not reading bugmail, still gone but not forever) 2004-04-25 14:37:12 PDT
When the patch is posted, I will ask a builder on MozillaZine if he is willing
to incorporate it into his builds. Then I can test it and report back if it works.
Comment 35 José Jeria 2004-04-26 23:23:51 PDT
*** Bug 241801 has been marked as a duplicate of this bug. ***
Comment 36 PikeUK 2004-04-27 05:45:08 PDT
Created attachment 147130 [details] [diff] [review]
Port of patch from seamonkey bug (original patch by jag)

This is a firefox version of jag's patch (attachment 125492 [details] [diff] [review]) from Bug 104778.

I played around with it a bit and discovered the problem I was having before.
Whenever window.content.document is accessed on a loading document, an
onLocationChange is triggered (I assume accessing document creates the relevant
object early which in turn triggers the event but I don't know).

The reason why a straight port of the patch from Bug 104778 didn't work is
because nsBrowserStatusHandler.onLocationChange (which is called whenever the
user switches tabs) calls updatePageTheme() which in turn accesses
window.content.document and indirectly triggers an onLocationChange. This new
onLocationChange makes the code think the page has loaded thus removing the
fake url that was being displayed and instead showing the true URL (which in
this case will be blank since the page hasn't really loaded yet).

This patch includes a dodgy workaround (copied from tabbrowser.xml) to prevent
the fake url from being cleared while inside updatePageTheme() (this wouldn't
be necessary if updatePageTheme() was called directly from
nsBrowserStatusHandler.onLocationChange rather than with a setTimeout but I
assume the timeout is there for a reason). If someone who understands all this
stuff better than me wants to do a nicer workaround please do.

p.s. This port and the original patch only deal with new tabs, not the current
tab and not new windows.
Comment 37 Asa Dotzler [:asa] 2004-04-27 10:49:43 PDT
*** Bug 229057 has been marked as a duplicate of this bug. ***
Comment 38 Mike Connor [:mconnor] 2004-04-30 12:54:46 PDT
I'm assuming updatePageTheme is called for live themeswitching?  We really need 
to toss that not-really-working "feature" until someone makes it work properly.
Comment 39 PikeUK 2004-04-30 15:55:22 PDT
(In reply to comment #38)
> I'm assuming updatePageTheme is called for live themeswitching?  We really need 
> to toss that not-really-working "feature" until someone makes it work properly.

updatePageTheme controls the CSS stylesheet switcher that appears in the statusbar.
Comment 40 888 Geek Help 2004-04-30 16:26:08 PDT
I moved for this bug to be upgraded to critical status, due to data loss. I just
tab loaded a large pile of links over two hours of researching on a website. All
the links were long stings but had a persistent not found url problem (.co
instead of .com) Instead of just changing the co to com all my tabbed urls were
completely blank. I consider the url stings to be valuable data, even if the url
was not found.

I experience this problem with blank not found urls daily and mostly it is just
annoying as I am usually able to re-find and copy paste then modify the url
before I attempt to open it. Still any url, even an invalid one, erased without
my permission is data loss. 

This is also a 10 out of 10 on the universal annoyance scale.  

Comment 41 Ben Goodger (use ben at mozilla dot org for email) 2004-05-04 14:51:54 PDT
+ing to invoke review. 
Comment 42 Tuukka Tolvanen (sp3000) 2004-06-16 06:05:54 PDT
*** Bug 247061 has been marked as a duplicate of this bug. ***
Comment 43 Fernando Korndorfer 2004-06-17 03:43:46 PDT
Use error pages (like Internet Explorer) instead of error dialogs (go to
about:config and change browser.xul.error_pages.enabled to true). This way, you
won't get a dialog every time an inactive tab fails to load and won't lose the URL.
Comment 44 Michael Favia 2004-06-17 10:35:11 PDT
Error page is an excellent addition to the solution in my opinion. That way it
doesnt disturb operation.
Comment 45 Unknown W. Brackets 2004-06-17 14:08:50 PDT
(In reply to comment #43)
> Use error pages (like Internet Explorer) instead of error dialogs (go to
> about:config and change browser.xul.error_pages.enabled to true). This way, you
> won't get a dialog every time an inactive tab fails to load and won't lose the
URL.

(In reply to comment #44)
> Error page is an excellent addition to the solution in my opinion. That way it
> doesnt disturb operation.

Even in that case, the url is mangled.  It would be better if the URL could be
kept - in both cases.

And, maybe I don't want the error pages (it is a pref, isn't it?) but still want
the url to persist?

-[Unknown]
Comment 46 Fernando Korndorfer 2004-06-17 14:58:44 PDT
(In reply to comment #45)
> Even in that case, the url is mangled.  It would be better if the URL could be
> kept - in both cases.
> 
> And, maybe I don't want the error pages (it is a pref, isn't it?) but still want
> the url to persist?
> 

I Agree. I posted #43 as a temporary workaround only. Additionally, there is no
option to enabled/disabled error pages in the 'Options' menu.
Comment 47 Bramus! 2004-06-18 06:40:20 PDT
*** Bug 246903 has been marked as a duplicate of this bug. ***
Comment 48 Ali Ebrahim 2004-06-20 21:31:45 PDT
*** Bug 247808 has been marked as a duplicate of this bug. ***
Comment 49 Mike Connor [:mconnor] 2004-07-05 13:56:11 PDT
Comment on attachment 147130 [details] [diff] [review]
Port of patch from seamonkey bug (original patch by jag)

review hell coming soon, time to load up for winter
Comment 50 PikeUK 2004-07-05 14:07:03 PDT
I dunno if this patch is really review-worthy, it works, but I'm not too happy
with the changes to updatePageTheme(). I couldn't find anything else that worked
though, I was hoping someone who knew the code better would think of a superior
alternative.
Comment 51 PikeUK 2004-07-12 16:06:00 PDT
*** Bug 250990 has been marked as a duplicate of this bug. ***
Comment 52 Ben Goodger (use ben at mozilla dot org for email) 2004-07-22 12:50:44 PDT
OK. 
Comment 53 Mike Connor [:mconnor] 2004-07-23 17:15:50 PDT
Comment on attachment 147130 [details] [diff] [review]
Port of patch from seamonkey bug (original patch by jag)

works for me.  We can improve this later as needed.
Comment 54 Mike Connor [:mconnor] 2004-07-23 17:20:51 PDT
-> patch author
Comment 55 Mike Connor [:mconnor] 2004-07-23 17:23:38 PDT
Created attachment 154162 [details] [diff] [review]
patch checked in to aviary
Comment 56 Mike Connor [:mconnor] 2004-07-23 17:34:47 PDT
fixed, branch and trunk.
Comment 57 Bill Mason 2004-08-01 22:26:25 PDT
*** Bug 253976 has been marked as a duplicate of this bug. ***
Comment 58 José Jeria 2004-08-02 00:40:27 PDT
When middle-clicking to load a page in a new tab seems to work fine, but when a
link is clicked on in an external application, the url is not prefilled. It is
only shown when a connection has been done. Can anyone confirm this? Or is this
the wrong bug for that?
Comment 59 José Jeria 2004-08-19 09:06:25 PDT
*** Bug 256143 has been marked as a duplicate of this bug. ***
Comment 60 psellhorst 2004-09-25 12:30:34 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040923
Firefox/0.10

This has not yet been fixed reliably. Even with a post 0.10 build,
this happens frequently when opening pages from slow sites in new tabs
(see comment 14). Often, though not always, the URL will be blank until
rendering starts which may be never if a "Net Reset Error" occurs.
With error pages enabled, it is only then that the URL bar will
finally be filled with a value (which in this case will be
"chrome://global/content/netError.xhtml?e=netReset&u=<site>").

This bug should probably be reopened. (There also other bugs still coming in
such as bug 261453.)
Comment 61 psellhorst 2004-10-02 18:21:00 PDT
When selecting bookmarks or history entries, the URL is not prefilled either.
Different bug or also covered by this one?
Comment 62 José Jeria 2004-10-08 11:14:31 PDT
bug 254714 deals with links opened from external applications being lost.
Comment 63 José Jeria 2004-10-14 07:29:13 PDT
This doesnt work anymore. Suggest to reopen. Build 20041013, Windows XP
Comment 64 Peter van der Woude [:Peter6] 2004-10-17 08:37:17 PDT
*** Bug 242535 has been marked as a duplicate of this bug. ***
Comment 65 Asher 2004-10-26 07:18:49 PDT
This is absolutely still an issue with the latest branch builds...this is
something that I feel very strongly should be fixed for 1.0.

It is incredibly frustrating to load a bunch of tabs in the background, only to
have some of them fail for whatever reason, and then not have the URL available
to retry it or see which one failed.
Comment 66 Ryan VanderMeulen [:RyanVM] 2004-10-26 10:05:24 PDT
(In reply to comment #65)
> This is absolutely still an issue with the latest branch builds...this is
> something that I feel very strongly should be fixed for 1.0.
> 
> It is incredibly frustrating to load a bunch of tabs in the background, only to
> have some of them fail for whatever reason, and then not have the URL available
> to retry it or see which one failed.

I'm also seeing this issue once again in recent nightlies.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041025
Firefox/1.0 (MOOX M2)
Comment 67 José Jeria 2004-10-26 10:14:39 PDT
Reopening, based on comments
Comment 68 Unknown W. Brackets 2004-10-27 02:00:49 PDT
If I may....

I think the originally reported issue is indeed fixed.  In fact, I have
experienced that it is fixed and will vouch for it being fixed.

What is NOT fixed is links opened in new tabs that are bad.  For example, let's
say I have a link going to www.thisisatpyo.com... if I were to middle click on
that link, the location bar would remain blank, it would time out, and there
would be no way to recover the bad URL - save to go back to the offending page
and copy the link.

This is different from actually typing the URL in, which does seem to work
properly.  It also is different from the URL going away once you switch tabs. 
Neither of these things happen, currently.... to my experience, at least.

I would very much like to see what is still wrong fixed, but I don't know if it
is already, or should be, a separate bug.  Nor do I know if it has any chance to
get fixed for 1.0.  I would love for it to be, but I would also completely
understand if it wasn't.

Thanks, and I hope that was helpful,
-[Unknown]
Comment 69 PikeUK 2004-10-27 02:06:11 PDT
Anyone know the regression window?

p.s. I really wish this patch hadn't been checked in (see comment 50) :-(
Comment 70 Jeff Walden [:Waldo] (remove +bmo to email) 2004-10-27 05:34:38 PDT
If this is to be fixed before 1.0, devs need to know about it, and merely
reopening isn't enough to let them know -- you also have to remove the
fixed-aviary1.0 keyword.  The List won't notice this has regressed unless you
remove the keyword.

Whether this will be fixed in time is uncertain.  I'd very much hope it would
be, but you never know.
Comment 71 Mike Connor [:mconnor] 2004-10-27 06:55:32 PDT
without an ultra-safe patch really soon, a new fix for this stands almost zero
chance of making it into 1.0
Comment 72 Michaël Arnauts 2004-10-27 07:01:04 PDT
can't this bug get some more attention? because, this bug was the first one I
noticed when I was a new firefox user. it would be a shame if this ended up in
the final product...
Comment 73 PikeUK 2004-10-27 08:12:25 PDT
Protecting getBrowserIndexForDocument (tabbrowser.xml) in the same way that
updatePageTheme was protected would improve the situation (I think there is a
third place that is causing problems but I can't find it at the moment).

It's a pretty dodgy solution but might be acceptable as a branch only fix. In
theory it should be safe, in practice I wouldn't like to say...
Comment 74 Adam Licata 2004-10-27 08:29:38 PDT
I can't reproduce the problem in comment 68 using Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0

After middle-clicking a bad link to open into a new tab, I get an error message
and the bad url is in the address bar.
Comment 75 chris hofmann 2004-10-27 16:42:10 PDT
I can reproduce either on
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026
Firefox/1.0RC1 
Comment 76 sairuh (rarely reading bugmail) 2004-10-27 17:14:19 PDT
hm, I cannot repro this issue with 2004102623-0.11 (which is 1.0RC1) on linux
fc2 with the tests in either comment 0 or comment 68. the bad url does persist
in the new tab.
Comment 77 Tracy Walker [:tracy] 2004-10-27 17:29:18 PDT
Using Firefox branch build 2004-10-26-23-0.11 (rc1), I was not able to reproduce
this with steps from comment 0 or comment 68.  

However, I was able to get a blank Loaction Field when opening a bad URL from
another application (in this case, a bad link from a Yahoo IM).
Comment 78 Unknown W. Brackets 2004-10-28 00:15:54 PDT
(In reply to comment #77)
> Using Firefox branch build 2004-10-26-23-0.11 (rc1), I was not able to reproduce
> this with steps from comment 0 or comment 68.  

I'm afraid I was using an older nightly than I thought (from mid/early October)
and having just updated to RC1... I see that my problem has been resolved.

Please forgive me.  But, I am experiencing the other issue you mentiond
(external links.)

-[Unknown]

Comment 79 José Jeria 2004-10-28 00:24:21 PDT
(In reply to comment #78)
> I am experiencing the other issue you mentiond
> (external links.)
> 

See comment 62
Comment 80 chris hofmann 2004-10-28 16:54:36 PDT
difficult, if not impossible to repro  --minusing
Comment 81 mmortal03 2004-11-04 14:23:57 PST
Yeah, if you enter a bad URL manually, it retains the bad URL.
But, if you open a bad URL by clicking on a link, it does NOT retain the bad URL.

For instance, lately, http://www.guru3d.com/ has been having issues with their
server.  I go to the site everyday by opening my bookmark into a new tab. 
Recently, I began to get an untitled tab for one of my regular pages, and by
process of elimination, I determined that it was the guru3d site.

So, do we reopen this bug, or do we create a new one.  I believe that the bug is
the same bug, and that we just never fixed it completely.
Comment 82 bugzilla2005 2004-11-13 17:07:10 PST
This is ridiculous.  Bug 211879 (which is a dupe of this, altough slightly
different: it is about a opening a slowly loading or unreachable URL in a new
tab, instead of typing it manually) reappeared in Firefox 1.0.  It was OK in RC1.
Comment 83 mmortal03 2004-11-13 17:44:20 PST
(In reply to comment #82)
> This is ridiculous.  Bug 211879 (which is a dupe of this, altough slightly
> different: it is about a opening a slowly loading or unreachable URL in a new
> tab, instead of typing it manually) reappeared in Firefox 1.0.  It was OK in RC1.
> 

Yeah, actually, that bug describes the current buggy behavior better than this
one does.  Whether or not it should still be considered the same bug, I don't know.
Comment 84 Malcolm Smith 2004-11-14 01:32:14 PST
(In reply to comment #83)
> Yeah, actually, that bug describes the current buggy behavior better than this
> one does.  Whether or not it should still be considered the same bug, I don't
know.
I suggest that this bug's summary should be changed to "Location bar empty until
page rendering starts". It should at least stop people from arguing about
exactly what the bug covers.
Comment 85 bugzilla 2004-11-26 17:56:01 PST
I'm not sure whether to put this here or on Bug 254714, but here goes.

When a clicked link on a tab fails to load after I click over to another tab,
when I switch back to that tab, the URL is gone, AND the back button no longer
works (it's grayed out). I can't get to the page I was trying to or any of the
previous pages that had been on that link without going into the History and
guessing. That makes it a much bigger dataloss problem than just using the 1 URL.

I couldn't find a mention of the Back button not working anywhere in an existing
bug. My guess is that most people browse news sites like I do, opening each
story in a separate tab, so that the tab has no back history to back up to. It's
definitely wiping out the entire history of that tab for me, though.

I've had this happen with Firefox 1.0 final on both Windows 2000 and Windows XP.
Comment 86 Mathias Wittlock 2004-12-04 11:39:28 PST
Since there's a rather big CC list for bug, I figured I'd share this extension
that'll provide a work around:
http://www.pikey.me.uk/mozilla/?extension=sfu

It's good for us users while waiting for the devs to find a solution and might
also be useful for the devs in finding that solution.
Comment 87 Robert Wiblin 2004-12-15 04:41:57 PST
(In reply to comment #86)
> Since there's a rather big CC list for bug, I figured I'd share this extension
> that'll provide a work around:
> http://www.pikey.me.uk/mozilla/?extension=sfu
> 
> It's good for us users while waiting for the devs to find a solution and might
> also be useful for the devs in finding that solution.

Is there any chance that someone can look at this extension and try to provide a
fix for this. This should have been fixed ages ago. This has actually gotten us
bad press! Read  http://www.applematters.com/comments.php?id=P213_0_1_0_C  "3.
Links opening in new tabs that failed to load also failed to retain the failed
address in the menu-bar for immediate attempts at reloading. This last one
finally persuaded me to switch back. I was tired of having to close the empty
tab, go back to the originating page, and re-click the link. Very annoying."
Comment 88 Simon Paquet [:sipaq] 2005-01-31 11:40:25 PST
*** Bug 278602 has been marked as a duplicate of this bug. ***
Comment 89 José Jeria 2005-02-03 13:43:22 PST
*** Bug 280961 has been marked as a duplicate of this bug. ***
Comment 90 Aniruddha Shankar 2005-03-06 19:20:07 PST
Bug still present in 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050227 Firefox/1.0.1

Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) 	-Wall
-W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -march=athlon-xp
-pipe -pthread -pipe
c++ 	gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) 
-fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-Wno-long-long -march=athlon-xp -pipe -Wno-deprecated -fshort-wchar -pthread
-pipe -I/usr/X11R6/include

Configure arguments
--disable-ldap --disable-mailnews --enable-crypto --disable-composer
--enable-single-profile --disable-profilesharing --enable-optimize=-O2
--enable-old-abi-compat-wrappers --disable-installer --disable-pedantic
--enable-crypto --with-system-jpeg --with-system-png --with-system-zlib
--without-system-nspr --enable-default-toolkit=gtk2 --disable-ipv6
--disable-xinerama --enable-xprint --enable-freetype2 --enable-freetypetest
--disable-debug --disable-tests --enable-reorder --enable-strip
--enable-strip-libs --enable-elf-dynstr-gc --enable-xft --enable-oji
--enable-mathml --disable-jsd --disable-xpctools --enable-gnomevfs --enable-svg
--enable-svg-renderer-cairo
--with-default-mozilla-five-home=/usr/lib/MozillaFirefox
--enable-extensions=cookie,xml-rpc,xmlextras,pref,transformiix,universalchardet,webservices,inspector,gnomevfs,negotiateauth,-venkman,gnomevfs
--prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --libdir=/usr/lib 
Comment 91 Alexander Derazhne 2005-03-31 15:11:33 PST
*** Bug 285857 has been marked as a duplicate of this bug. ***
Comment 92 Yoni Gilad 2005-03-31 15:59:16 PST
I found a way to reproduce this bug. It seems that it only happens when you
quickly open 2 or more links in new tabs. For example, middle-click the
following link twice quickly: http://2.3.4.5/

The first opened tab will have the URL, but the second tab will have a blank
location bar until it times out.

Tested on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050329 Firefox/1.0+
Comment 93 Yoni Gilad 2005-03-31 19:54:17 PST
Oops. Disregard my last comment - the behavior I described there comes from
having the Googlebar extension installed. Without Googlebar this bugs shows
itself on every tab switch to a bad link.

Anyway, this bug occurs because onLocationChange is called on tab switch. It
then assumes the page has been loaded and resets the URL. Patch to follow.
Comment 94 Yoni Gilad 2005-03-31 20:06:49 PST
Created attachment 179240 [details] [diff] [review]
patch

onLocationChange can be called from various unexpected places while the new tab
is loading, and then resets the URL. This patch works around this problem by
comparing the loaded URL to about:blank (which means the page hasn't been
loaded yet) before resetting.
Comment 95 Aniruddha Shankar 2005-03-31 22:19:40 PST
re: comment #94
umm... so if I patch firefox-1.0.2-source.tar.bz2 with yoni's patch, will the
bug be fixed?
Comment 96 PikeUK 2005-04-01 02:01:19 PST
Comment on attachment 179240 [details] [diff] [review]
patch

A slight issue with this patch is that if you try to visit about:blank (e.g. if
it's your homepage and you press the Home button) while a tab is still loading,
the URL bar is not blanked.

p.s. The hack that was added to updatePageStyles in the previous patch needs to
be removed since it broke about a week after it was checked in. I'm not sure
whether you want to add that to your patch, if not I'll create a separate patch
to remove it.
Comment 97 Yoni Gilad 2005-04-01 04:46:56 PST
Created attachment 179266 [details] [diff] [review]
better patch

The "fake" onLocationChange event has aRequest==null, so we can check for that
instead of special-casing about:blank. 

This allows us to remove the related hack from both updatePageStyles and from
updateCurrentBrowser in tabbrowser.xml.
Comment 98 Worcester12345 2005-04-01 13:42:44 PST
Request blocking 1.0.3 since a patch exists and this is a dataloss bug.
Comment 99 Alexander Derazhne 2005-04-01 15:18:37 PST
I'll very grateful to anybody who tell me how to use this patch. Or I have only 
to wait 1.0.3 ?
BTW, it _can_ be similar problem with non-browsable urls: when url open in the 
new tab and this url refer to entity which browser can not process, but only 
save (or save and call handler, ex. MediaPlayer) - new tab is created, but get 
name "Untitled" and no url in the navigation bar. All of comment #6 is valid 
for this case too.
Does this patch fix this problem too?
Comment 100 Yoni Gilad 2005-04-01 16:46:29 PST
(In reply to comment #99)

This patch also covers new tabs that result in a download.
Comment 101 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-04-04 11:20:47 PDT
We're not taking changes on 1.0.x other than security fixes and regressions
along the 1.0.x series (i.e., regressions from security fixes).
Comment 102 José Jeria 2005-04-05 01:44:37 PDT
*** Bug 289064 has been marked as a duplicate of this bug. ***
Comment 103 Worcester12345 2005-04-05 07:32:08 PDT
(In reply to comment #101)
> We're not taking changes on 1.0.x other than security fixes and regressions
> along the 1.0.x series (i.e., regressions from security fixes).

Even 1.0.4? Even for DATALOSS bugs? I thought serious DATALOSS bugs would be
considered for blocking these builds.
Comment 104 Michael Lefevre 2005-04-05 08:03:34 PDT
Even 1.0.4, even dataloss/serious bugs. If you want to talk about that decision,
bugzilla isn't the place to do it (it was covered in a MozillaZine frontpage
article and there's some discussion there). They initially locked the 1.0.x
flags - if people nominate non-security issues, they'll lock them again. Bug
fixing will be done for 1.1.
Comment 105 José Jeria 2005-04-13 01:45:46 PDT
*** Bug 290130 has been marked as a duplicate of this bug. ***
Comment 106 PikeUK 2005-04-27 08:33:37 PDT
*** Bug 274804 has been marked as a duplicate of this bug. ***
Comment 107 Aniruddha Shankar 2005-05-15 01:46:51 PDT
The vast majority of URLs on the Internet are valid ones and the majority of
Internet connections that F/L/OSS developers use are broadband ones. Because of
this, many of those on broadband connections fail to see how frustrating this
bug is. For those in developing nations, where broadband penetration is very
sparse, and shared dialup connections are the norm, being able to click reload
on a URL when it is not retrieved because your Internet link is saturated or
flaky is ESSENTIAL. If your link is saturated or flaky, you quickly develop the
patience you need to click reload a few times to make the webpage display. What
you don't develop is the ability to scry the actual URL from the several that
you are usually trying to load.

My intent in writing this addendum to this bug is to shed light on the
particularities of usage conditons that might not be immediately familiar to
many software developers. I respect and am extremely grateful for the huge
amount of work that has gone into F/L/OSS software in general and Firefox in
particular, I'm just trying to emphasise why this bug is critical for myself and
for the people whose machines I administer.

I tried patching mozilla-firefox-1.0.4 with Yoni Gilad's patch and the patch
failed. I'm attaching the output of the failed patch.
Comment 108 Aniruddha Shankar 2005-05-15 01:50:16 PDT
Created attachment 183625 [details]
Failed Patch Attempt
Comment 109 Aniruddha Shankar 2005-05-15 01:50:50 PDT
Created attachment 183626 [details]
Failed Patch Attempt
Comment 110 Aniruddha Shankar 2005-05-15 01:51:27 PDT
Created attachment 183627 [details]
Failed Patch Attempt
Comment 111 Justin Kerk 2005-05-15 13:27:52 PDT
comment #107: Try the workaround in comment #43 (enabling error pages instead of
error dialogs). I use it with no problems, and I can click the reload button on
the error page if a page fails to load.
Comment 112 Travis Evans 2005-05-16 11:05:36 PDT
Enabling error pages helps, but it's not a perfect solution.  It seems that you
often have to wait for the attempt to time out before you can try it again.

There's also one serious issue with error pages (on my browser, anyway)--it
"eats" the last page.  So you can't click the Back button if an error occurs,
because the last page is lost.
Comment 113 Fernando Korndorfer 2005-05-16 13:05:03 PDT
(In reply to comment comment #112)

See comment #86.
Albeit it still breaks the back button.
Comment 114 Justin Kerk 2005-05-16 14:28:56 PDT
Error pages breaking the back button was fixed in trunk builds by bug 157004.
Comment 115 hlpvhfyakppapw 2005-05-21 19:14:22 PDT
This bug is absolutely devastating. You can't even imagine how annoying it has
been. I'd rather have this fixed over any new feature you can come with. It
makes me seriously consider dumping FF, which has otherwise provided a perfect
browsing experience.
Comment 116 John Vandenberg 2005-05-30 04:40:55 PDT
*** Bug 268915 has been marked as a duplicate of this bug. ***
Comment 117 José Jeria 2005-06-04 12:22:12 PDT
*** Bug 296634 has been marked as a duplicate of this bug. ***
Comment 118 José Jeria 2005-06-09 11:14:25 PDT
*** Bug 297053 has been marked as a duplicate of this bug. ***
Comment 119 Mike Connor [:mconnor] 2005-06-15 19:31:33 PDT
not a blocker, will get to the review ASAP
Comment 120 Kevin Brosnan 2005-06-17 13:40:22 PDT
*** Bug 298040 has been marked as a duplicate of this bug. ***
Comment 121 José Jeria 2005-08-06 06:11:26 PDT
*** Bug 303668 has been marked as a duplicate of this bug. ***
Comment 122 Tim Connors 2005-08-06 07:29:13 PDT
(In reply to comment #119)
> not a blocker, will get to the review ASAP

OK cool.

Could I just remind you of your comment 28, written about.... 16 months ago.

We seem to be past version 1.0 now, and it's still as annoying as it was then.

Bug fixes getting treatment ahead of feature creep^W^Wbloat sure would be nice.
Comment 123 Mike Connor [:mconnor] 2005-08-06 07:56:04 PDT
Actually, I can't reproduce this in a current nightly build.  Not sure if
patches elsewhere have fixed this more completely, or if the switch to xul error
pages reduced this to a corner case (i.e. only happens if you switch back to
error dialogs).
Comment 124 José Jeria 2005-08-06 08:12:12 PDT
(In reply to comment #123)
> Actually, I can't reproduce this in a current nightly build.  

Yeah, this works for me as well. It is still broken though when you click on a
link in an external app like Thunderbird. 
Comment 125 José Jeria 2005-08-06 08:16:40 PDT
Ah, that is bug 254714 (comment 62), sorry for spam
Comment 126 wy2lam 2005-09-11 22:48:40 PDT
(In reply to comment #28)

It depends how you define a "right" way.

Say, if we add a check whenever we clear the URL bar so that if it is not
already empty, don't empty it - In fact, I see no reason why the address bar
should *EVER* be cleared other than immediately after creation as an
initialization, or by direct editting from the user.

So, if we can add an option to "never clear URL bar", I think it will be a fix
in the "right" way.

> there's underlying issues that have prevented this from being fixed thus far, 
> not trivial whatsoever to fix the "right" way,  however I anticipate this will 
> be resolved before 1.0.
> 
> Please keep in mind the current priorities from a development/testing 
> perspective is to make 0.9 "feature-complete" meaning that all of the major 
> features targeted for 1.0 will be done and active.  This means that plain old 
> fixing bugs is secondary to getting that done.  The plan is to have 0.9 pretty 
> much the finished product, then harden and polish the product on the stable 
> branch.
> 
> Setting blocking flags inappropriately will only get your bugzilla privileges 
> removed, btw.
Comment 127 Mike Connor [:mconnor] 2005-09-14 21:51:48 PDT
Comment on attachment 179266 [details] [diff] [review]
better patch

let's get this on trunk for some testing, but this looks good.
Comment 128 Jesse Ruderman 2005-10-20 00:58:19 PDT
WFM trunk and MOZILLA_1_8_BRANCH with error pages disabled.  Is attachment
179266 [details] [diff] [review] still needed?
Comment 129 BoffinbraiN 2005-11-08 17:53:43 PST
Just thought I'd mention, this bug is fixed in 1.5 PR.  Address stays.  Great.

Sorry if I'm being ignorant, but doesn't that mean this bug is resolved?

I'm relatively new to Bugzilla and I know the system is quite complicated, but if this problem is no longer present in the latest version of the product, why persist?
Comment 130 Adam Guthrie 2005-11-10 11:53:33 PST
WFM per Jesse's and David's comments. Please reopen if you object.
Comment 131 PikeUK 2005-11-10 14:11:17 PST
Mr. Connor review +ed attachment 179266 [details] [diff] [review] which has some nice cleanup in it, but it was never checked in, assuming it still works, is there any chance of that happening (or at least checking in the hack removal parts)?
Comment 132 Mike Connor [:mconnor] 2005-11-11 08:52:50 PST
If the patch can get cleaned up, great, just split that off and reattach to a new bug. r=me still applies unless there's significant changes, but that's a trunk thing, obviously.
Comment 133 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-11-11 09:00:34 PST
I filed bug 316059 for attachment 179266 [details] [diff] [review].
Comment 134 mmortal03 2006-01-10 12:16:11 PST
I am fairly certain that some portion of this bug has still occured in isolated cases while browsing, but the majority of this bug is obviously fixed, and at the moment, I have no test case, anyway.  I will continue to look for one.

Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Comment 135 Phil Ringnalda (:philor, back in August) 2006-11-11 00:50:06 PST
*** Bug 259026 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.