Closed Bug 231393 Opened 21 years ago Closed 19 years ago

Tab URL does not persist on bad links if tabs switched

Categories

(Firefox :: Tabbed Browser, defect, P4)

Product:
Firefox
Component:
Tabbed Browser
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Firefox1.5

People

(Reporter: moz-bugzilla2, Assigned: yonigilad)

References

Details

(Keywords: dataloss, polish)

Attachments

(6 files, 1 obsolete file)

Port of patch from seamonkey bug (original patch by jag)
12.59 KB, patch
mconnor
: review+
Details | Diff | Splinter Review
patch checked in to aviary
10.70 KB, patch
Details | Diff | Splinter Review
better patch
5.58 KB, patch
mconnor
: review+
Details | Diff | Splinter Review
Failed Patch Attempt
6.12 KB, application/octet-stream
Details
Failed Patch Attempt
6.12 KB, application/octet-stream
Details
Failed Patch Attempt
6.12 KB, application/octet-stream
Details 
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.
Requesting blocking. This could be considered a dataloss situation and was
addressed in Seamonkey in Bug 103720.
Flags: blocking0.8?
Severity: normal → major
OS: Windows XP → All
Bug mentioned in comment 0 was wrong, should be bug 203102.
Thanks, you're correct.
_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".
this isn't a grandma-killing bug.
Flags: blocking0.8? → blocking0.8-
QA Contact: mconnor
Keywords: dataloss
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. 
Full ACK! This one really sucks ;)
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?
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
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.
(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.


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.
Flags: blocking0.9?
*** Bug 211879 has been marked as a duplicate of this bug. ***
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.
*** Bug 233891 has been marked as a duplicate of this bug. ***
Bug still persists with Firefox 0.8 and with nightly build of 15th February 2004
*** Bug 234885 has been marked as a duplicate of this bug. ***
*** Bug 235378 has been marked as a duplicate of this bug. ***
*** Bug 236625 has been marked as a duplicate of this bug. ***
(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.
*** Bug 239245 has been marked as a duplicate of this bug. ***
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.
(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.
(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.
Flags: blocking0.9? → blocking0.9+
Flags: blocking0.9+ → blocking0.9?
If this problem were minor, people wouldn't report is so often ( go count the
duplicates/comments) :rolleyes:
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.
Flags: blocking0.9? → blocking0.9+
(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?

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.
Flags: blocking0.9+ → blocking0.9?
Keywords: polish
*** Bug 240517 has been marked as a duplicate of this bug. ***
(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).
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 ...
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 :)
Assignee: firefox → mconnor
Flags: blocking0.9? → blocking0.9-
Target Milestone: --- → Firefox1.0beta
(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 :-).
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.
*** Bug 241801 has been marked as a duplicate of this bug. ***
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.
*** Bug 229057 has been marked as a duplicate of this bug. ***
Flags: blocking1.0?
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.
(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.
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.  


+ing to invoke review.
Flags: blocking1.0? → blocking1.0+
*** Bug 247061 has been marked as a duplicate of this bug. ***
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.
Error page is an excellent addition to the solution in my opinion. That way it
doesnt disturb operation.
(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]
(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.
*** Bug 246903 has been marked as a duplicate of this bug. ***
*** Bug 247808 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0RC1?
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
Attachment #147130 - Flags: review?(mconnor)
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.
*** Bug 250990 has been marked as a duplicate of this bug. ***
OK.
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1+
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.
Attachment #147130 - Flags: review?(mconnor) → review+
-> patch author
Assignee: mconnor → pike
fixed, branch and trunk.
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
*** Bug 253976 has been marked as a duplicate of this bug. ***
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?
*** Bug 256143 has been marked as a duplicate of this bug. ***
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.)
When selecting bookmarks or history entries, the URL is not prefilled either.
Different bug or also covered by this one?
bug 254714 deals with links opened from external applications being lost.
This doesnt work anymore. Suggest to reopen. Build 20041013, Windows XP
*** Bug 242535 has been marked as a duplicate of this bug. ***
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.
(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)
Reopening, based on comments
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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]
Anyone know the regression window?

p.s. I really wish this patch hadn't been checked in (see comment 50) :-(
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.
Keywords: fixed-aviary1.0
without an ultra-safe patch really soon, a new fix for this stands almost zero
chance of making it into 1.0
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...
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...

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


(In reply to comment #78)
> I am experiencing the other issue you mentiond
> (external links.)
> 

See comment 62

difficult, if not impossible to repro  --minusing
Flags: blocking-aviary1.0PR+
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+
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.
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.

(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.
(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.
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.
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.
(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."
Flags: blocking-aviary1.1?
*** Bug 278602 has been marked as a duplicate of this bug. ***
*** Bug 280961 has been marked as a duplicate of this bug. ***
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 
*** Bug 285857 has been marked as a duplicate of this bug. ***
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+
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.
Attached patch patch (obsolete) — — Splinter Review 
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.
Attachment #179240 - Flags: review?(mconnor)
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 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.
Attached patch better patch — — Splinter Review 
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.
Attachment #179240 - Attachment is obsolete: true
Attachment #179266 - Flags: review?(mconnor)
Attachment #179240 - Flags: review?(mconnor)
Assignee: pike → yonigilad
Status: REOPENED → NEW
Request blocking 1.0.3 since a patch exists and this is a dataloss bug.
Flags: blocking-aviary1.0.3?
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?
(In reply to comment #99)

This patch also covers new tabs that result in a download.
Status: NEW → ASSIGNED
Component: General → Tabbed Browser
Target Milestone: Firefox1.0beta → Firefox1.1
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).
Flags: blocking-aviary1.0.3? → blocking-aviary1.0.3-
*** Bug 289064 has been marked as a duplicate of this bug. ***
(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.
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.
*** Bug 290130 has been marked as a duplicate of this bug. ***
*** Bug 274804 has been marked as a duplicate of this bug. ***
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.
Attached file Failed Patch Attempt — 

    
    

    
  

      
      
      
      

        Attached file
          
        Failed Patch Attempt
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        Failed Patch Attempt
        — 
      

    


  

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
(In reply to comment comment #112)

See comment #86.
Albeit it still breaks the back button.

    
    

    
  
Error pages breaking the back button was fixed in trunk builds by bug 157004.

    
    

    
  
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.

    
  
Blocks: majorbugs

    
  
No longer blocks: majorbugs

    
    

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

    
    

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

    
    

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

    
    

    
  
not a blocker, will get to the review ASAP
Flags: blocking-aviary1.1? → blocking-aviary1.1-

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
Ah, that is bug 254714 (comment 62), sorry for spam

    
    

    
  
(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 on attachment 179266 [details] [diff] [review]
better patch

let's get this on trunk for some testing, but this looks good.

        Attachment #179266 -
        Flags: review?(mconnor) → review+

    
    

    
  
WFM trunk and MOZILLA_1_8_BRANCH with error pages disabled.  Is attachment
179266 [details] [diff] [review] still needed?

    
    

    
  
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?

    
    

    
  
WFM per Jesse's and David's comments. Please reopen if you object.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → WORKSFORME

    
    

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

    
    

    
  
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.

    
    

    
  
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

    
    

    
  
*** Bug 259026 has been marked as a duplicate of this bug. ***
QA Contact: mconnor → tabbed.browser

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: