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)
Tracking
()
RESOLVED
WORKSFORME
Firefox1.5
People
(Reporter: moz-bugzilla2, Assigned: yonigilad)
References
Details
(Keywords: dataloss, polish)
Attachments
(6 files, 1 obsolete file)
12.59 KB,
patch
|
mconnor
:
review+
|
Details | Diff | Splinter Review |
10.70 KB,
patch
|
Details | Diff | Splinter Review | |
5.58 KB,
patch
|
mconnor
:
review+
|
Details | Diff | Splinter Review |
6.12 KB,
application/octet-stream
|
Details | |
6.12 KB,
application/octet-stream
|
Details | |
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.
Reporter | ||
Comment 1•21 years ago
|
||
Requesting blocking. This could be considered a dataloss situation and was addressed in Seamonkey in Bug 103720.
Flags: blocking0.8?
Updated•21 years ago
|
Severity: normal → major
Reporter | ||
Updated•21 years ago
|
OS: Windows XP → All
Comment 2•21 years ago
|
||
Bug mentioned in comment 0 was wrong, should be bug 203102.
Reporter | ||
Comment 3•21 years ago
|
||
Thanks, you're correct.
Comment 4•21 years ago
|
||
_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•21 years ago
|
||
this isn't a grandma-killing bug.
Flags: blocking0.8? → blocking0.8-
QA Contact: mconnor
Comment 6•21 years ago
|
||
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•21 years ago
|
||
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?
Comment 9•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
(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•21 years ago
|
||
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.
Updated•21 years ago
|
Flags: blocking0.9?
Comment 13•21 years ago
|
||
*** Bug 211879 has been marked as a duplicate of this bug. ***
Comment 14•21 years ago
|
||
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•21 years ago
|
||
*** Bug 233891 has been marked as a duplicate of this bug. ***
Comment 16•21 years ago
|
||
Bug still persists with Firefox 0.8 and with nightly build of 15th February 2004
Comment 17•21 years ago
|
||
*** Bug 234885 has been marked as a duplicate of this bug. ***
Comment 18•20 years ago
|
||
*** Bug 235378 has been marked as a duplicate of this bug. ***
Comment 19•20 years ago
|
||
*** Bug 236625 has been marked as a duplicate of this bug. ***
Comment 20•20 years ago
|
||
(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•20 years ago
|
||
*** Bug 239245 has been marked as a duplicate of this bug. ***
Comment 22•20 years ago
|
||
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.
Comment 24•20 years ago
|
||
(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•20 years ago
|
||
If this problem were minor, people wouldn't report is so often ( go count the duplicates/comments) :rolleyes:
Comment 26•20 years ago
|
||
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+
Comment 27•20 years ago
|
||
(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•20 years ago
|
||
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
Comment 29•20 years ago
|
||
*** Bug 240517 has been marked as a duplicate of this bug. ***
Comment 30•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
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
Comment 33•20 years ago
|
||
(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.
Comment 35•20 years ago
|
||
*** Bug 241801 has been marked as a duplicate of this bug. ***
Comment 36•20 years ago
|
||
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•20 years ago
|
||
*** Bug 229057 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking1.0?
Comment 38•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
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.
Updated•20 years ago
|
Priority: -- → P4
Comment 42•20 years ago
|
||
*** Bug 247061 has been marked as a duplicate of this bug. ***
Comment 43•20 years ago
|
||
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•20 years ago
|
||
Error page is an excellent addition to the solution in my opinion. That way it doesnt disturb operation.
Comment 45•20 years ago
|
||
(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•20 years ago
|
||
(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•20 years ago
|
||
*** Bug 246903 has been marked as a duplicate of this bug. ***
Comment 48•20 years ago
|
||
*** Bug 247808 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking-aviary1.0RC1?
Comment 49•20 years ago
|
||
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)
Comment 50•20 years ago
|
||
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•20 years ago
|
||
*** Bug 250990 has been marked as a duplicate of this bug. ***
Comment 53•20 years ago
|
||
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+
Comment 55•20 years ago
|
||
Comment 56•20 years ago
|
||
fixed, branch and trunk.
Comment 57•20 years ago
|
||
*** Bug 253976 has been marked as a duplicate of this bug. ***
Comment 58•20 years ago
|
||
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•20 years ago
|
||
*** Bug 256143 has been marked as a duplicate of this bug. ***
Comment 60•20 years ago
|
||
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•20 years ago
|
||
When selecting bookmarks or history entries, the URL is not prefilled either. Different bug or also covered by this one?
Comment 62•20 years ago
|
||
bug 254714 deals with links opened from external applications being lost.
Comment 63•20 years ago
|
||
This doesnt work anymore. Suggest to reopen. Build 20041013, Windows XP
Comment 64•20 years ago
|
||
*** Bug 242535 has been marked as a duplicate of this bug. ***
Comment 65•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
Reopening, based on comments
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 68•20 years ago
|
||
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•20 years ago
|
||
Anyone know the regression window? p.s. I really wish this patch hadn't been checked in (see comment 50) :-(
Comment 70•20 years ago
|
||
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
Comment 71•20 years ago
|
||
without an ultra-safe patch really soon, a new fix for this stands almost zero chance of making it into 1.0
Comment 72•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
(In reply to comment #78) > I am experiencing the other issue you mentiond > (external links.) > See comment 62
Comment 80•20 years ago
|
||
difficult, if not impossible to repro --minusing
Flags: blocking-aviary1.0PR+
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+
Comment 81•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
(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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
(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."
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Comment 88•20 years ago
|
||
*** Bug 278602 has been marked as a duplicate of this bug. ***
Comment 89•20 years ago
|
||
*** Bug 280961 has been marked as a duplicate of this bug. ***
Comment 90•19 years ago
|
||
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•19 years ago
|
||
*** Bug 285857 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 92•19 years ago
|
||
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+
Assignee | ||
Comment 93•19 years ago
|
||
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.
Assignee | ||
Comment 94•19 years ago
|
||
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)
Comment 95•19 years ago
|
||
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•19 years ago
|
||
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.
Assignee | ||
Comment 97•19 years ago
|
||
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)
Assignee | ||
Updated•19 years ago
|
Attachment #179240 -
Flags: review?(mconnor)
Comment 98•19 years ago
|
||
Request blocking 1.0.3 since a patch exists and this is a dataloss bug.
Flags: blocking-aviary1.0.3?
Comment 99•19 years ago
|
||
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?
Assignee | ||
Comment 100•19 years ago
|
||
(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-
Comment 102•19 years ago
|
||
*** Bug 289064 has been marked as a duplicate of this bug. ***
Comment 103•19 years ago
|
||
(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•19 years ago
|
||
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•19 years ago
|
||
*** Bug 290130 has been marked as a duplicate of this bug. ***
Comment 106•19 years ago
|
||
*** Bug 274804 has been marked as a duplicate of this bug. ***
Comment 107•19 years ago
|
||
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•19 years ago
|
||
Comment 109•19 years ago
|
||
Comment 110•19 years ago
|
||
Comment 111•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
(In reply to comment comment #112) See comment #86. Albeit it still breaks the back button.
Comment 114•19 years ago
|
||
Error pages breaking the back button was fixed in trunk builds by bug 157004.
Comment 115•19 years ago
|
||
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•19 years ago
|
||
*** Bug 268915 has been marked as a duplicate of this bug. ***
Comment 117•19 years ago
|
||
*** Bug 296634 has been marked as a duplicate of this bug. ***
Comment 118•19 years ago
|
||
*** Bug 297053 has been marked as a duplicate of this bug. ***
Comment 119•19 years ago
|
||
not a blocker, will get to the review ASAP
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Comment 120•19 years ago
|
||
*** Bug 298040 has been marked as a duplicate of this bug. ***
Comment 121•19 years ago
|
||
*** Bug 303668 has been marked as a duplicate of this bug. ***
Comment 122•19 years ago
|
||
(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•19 years ago
|
||
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•19 years ago
|
||
(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•19 years ago
|
||
Ah, that is bug 254714 (comment 62), sorry for spam
Comment 126•19 years ago
|
||
(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•19 years ago
|
||
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+
Comment 128•19 years ago
|
||
WFM trunk and MOZILLA_1_8_BRANCH with error pages disabled. Is attachment 179266 [details] [diff] [review] still needed?
Comment 129•19 years ago
|
||
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•19 years ago
|
||
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
Comment 131•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
I filed bug 316059 for attachment 179266 [details] [diff] [review].
Comment 134•19 years ago
|
||
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•18 years ago
|
||
*** Bug 259026 has been marked as a duplicate of this bug. ***
Updated•15 years ago
|
QA Contact: mconnor → tabbed.browser
You need to log in
before you can comment on or make changes to this bug.
Description
•