Closed Bug 103720 Opened 20 years ago Closed 18 years ago

Open in new tab should prefill URI in location bar (URL is lost and replaced with "about:blank" when switching tabs if the page fails to load) (may also happen with new window?)

Categories

(SeaMonkey :: Tabbed Browser, defect, P1)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.4beta

People

(Reporter: cesarb, Assigned: jag+mozilla)

References

(
URL
)

Details

(Keywords: dataloss, Whiteboard: [adt3])

Attachments

(3 files, 4 obsolete files)

Allows mailnews windows to open links in new browser tabs
4.26 KB, patch
Details | Diff | Splinter Review
a patch
2.05 KB, patch
Details | Diff | Splinter Review
HTML page with different types of hyperlinks pointing to a non existent domain "bugzila.mozilla.org"
869 bytes, text/html
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20011005
BuildID:    2001100514

When you open a URL in a new tab and the loading fails (for instance, host is
down, you are using ECN and the site blocks it, or your DNS is just plain slow),
you are left with a untitled tab with no URL. If you already left the original
page, you won't know what should be there.

Reproducible: Always
Steps to Reproduce:
1. Right-click on the URL and chose Open in a new tab

Actual Results:  The URL bar is empty

Expected Results:  The URL bar should have http://cvs.mozilla.org/

This is the tabbed browser version of a similar bug with Open in new window
(fixed a long time ago); I can't find it right now.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
*** Bug 107401 has been marked as a duplicate of this bug. ***
*** Bug 111440 has been marked as a duplicate of this bug. ***
Bug 63334 was the similar bug with Open in new window.
*** Bug 111713 has been marked as a duplicate of this bug. ***
Modifies contentAreaUtils JS to enable non browser windowtypes to open links in
a new tab if the client has a navigator window open.
OS: Linux → All
Hardware: PC → All
Reassigning to new component owner.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
*** Bug 122014 has been marked as a duplicate of this bug. ***
QA Contact: blaker → sairuh
this seems to work for me --then again, i couldn't repro with the test url since
i get connect refused msgs. but i tested with other url's and they seem to work
fine, using 2002.02.13 bits.

reopen if there's a reproducible case for this.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
The fact that you get connection refused is the POINT of the test URL, sairuh.

I believe he's asking for the URL to be loaded into the URL bar before we even
attempt to load the page, so that the location will be still available if the
page doesn't load.

See also bug 117100 and there's another one about about:blank.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Filed bug 125589 about this new connection refused dead tab not being able to
switch out via keyboad. Fixes might be related.
*** Bug 121454 has been marked as a duplicate of this bug. ***
Bug still present in 2002032911/Linux - Essentially the location bar is not
filled until there's something to display. If there's nothing to display the
location bar never gets filled and so misery ensures.

This was happening long before the bug mentioned in comment #10 occured.
As mentioned in Comment #3, Bug 63334 was pretty much the same issue, except
with new windows instead of tabs. That one was fixed by jag, apparently for Bug
70682. I know I would certainly appreciat a fix for this one. Incidentally, when
this one is fixed, it is likely that Bug 125772 will then be pertinent to this.
*** Bug 138794 has been marked as a duplicate of this bug. ***
Related to bug 104778?
*** Bug 143504 has been marked as a duplicate of this bug. ***
*** Bug 146198 has been marked as a duplicate of this bug. ***
I think that this is quite important to get fixed by 1.0, since it seriously
affects the usability of the tabbed browsing feature. I'm running into this bug
multiple times per day and it's getting highly annoying.

Anyone care to set the "mozilla1.0" keyword?
Malcolm i totaly agree, same thing happens here all the time, it is *anoying*,
especially with this 56k conection, time outs happen a lot and this bug really
irritates me! 
Tabbed browsing is a great, thing but this bug makes tabs suck a lit bit. 
*** Bug 139034 has been marked as a duplicate of this bug. ***
*** Bug 154298 has been marked as a duplicate of this bug. ***
A related bug 124231 on manual entered URL's disappearing was fixed sometime
between 0.9.9 and 1.1 alpha.
*** Bug 155079 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.1
When creating a tab, would setting the src attribute of the browser give you
somewhere to find the URL later for when the initial document didn't load?
*** Bug 156237 has been marked as a duplicate of this bug. ***
*** Bug 156406 has been marked as a duplicate of this bug. ***
*** Bug 162390 has been marked as a duplicate of this bug. ***
*** Bug 172446 has been marked as a duplicate of this bug. ***
*** Bug 174544 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → pmac
Still seeing that on windows 2k (netscape trunk build: 2002-10-24-08-TRUNK0
> Still seeing that on windows 2k (netscape trunk build: 2002-10-24-08-TRUNK0

Of course you do! Nobody has only tried to do something about it so far. This
error still annoys me like hell three times a day.
This bug is also seriously annoying me (and doubtless many others). Does anyone
have any plans to fix this, considering that the target milestone of
mozilla1.0.1 has long passed?

And I think the severity needs upgrading from minor to at least normal, if not
major (since it's a major usability issue now tabbed browsing is one of
Mozilla's main advantages).
Serverity Minor is defined as: "minor loss of function, or other problem where
easy workaround is present". Since there is no easy workaround present, there is
no workaround present at all (not even a hard one), it's actually not minor, so
I will set it to normal.

I will set a new target milestone, being 1.3alpha (it won't make it to 1.2 final
release for sure, but right after that, people should fix this very old bug). I
give it highest priority for 1.3alpha (should be one of the first things fixed
for 1.3alpha). I also updated the keyword to represent the change.


I have no idea why this is so hard to fix, as I don't know how Mozilla works. I
mean, when a new tab is opened, can't the current tab pass the URL to the new
tab and if page load files, can't the tab put the URL it should have loaded into
the address bar when selected? I mean, if I only have one page open and page
loading fails, there will still be written in the address bar what I wrote last.

I don't know why the problem even exists at all. I mean, does Mozilla open the
tab, initiate the network transfer and the network code will then tell the tab
which URL it is displaying after the page loaded? Why not giving the tab just
the URL and the tab will itself initiate the network transfer?

Peter, this bug is assigned to you. Could you please explain us, the stupid
users where exactly the problem is? (and please in such a way that we can all
understand it). Is a full redesign of the tab code necessary to fix this bug? Is
it that you can't fix this bug or that you don't want to fix this bug, because
you think it is no bug?

My C coding experience is too little to code that myself and it's not easy to
jump into such a huge project like Mozilla (not knowing all the implementation
details and the projected is poorly documented for outstanding people) I may do
more harm than good. But if you tell us that you can't fix that bug (because you
don't have time or because it's not a trivial thing to do), then maybe we can
find someone (from the Mozilla project, from a related project or from the
OpenSource community who already worked with the Mozilla source code) who can.
This bug is as old as tabs in Mozilla and just like in case of some other bugs,
I see absolute no progress so far. It's not a shame to ask for help.
Severity: minor → normal
Keywords: mozilla1.1 → mozilla1.3
Priority: -- → P1
Target Milestone: mozilla1.0.1 → mozilla1.3alpha
target milestone is reserved for the bug owner.

it's a js/xbl bug. at some point in the future you should be able to use venkman
(set not to exclude browser files) to watch the behavior and design a fix. until
then you could use traditional "printf" style debugging (the js function is
"dump") in tabbrowser.xml. if you'd like help you could ask on irc.

also note that neil already gave a suggestion. here's mine:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/global/resources/content/bindings/tabbrowser.xml&rev=1.63&mark=677,186,225#216
Target Milestone: mozilla1.3alpha → ---
Have you made any changes in the tabbrowser.xml file? The lines you are coloring
(186, 225 and 677) are identical to the lines of the current tabbrowser.xml in
my nightly build. Are these the lines you suggest to change or is there a change
that I have overlooked?
There was another bug very similar to this, only it was for links opened in new
windows.  Somebody who isn't too busy at work should hunt down that old bug and
check out how it was fixed and who fixed it.
I've got a very lame hack in that it keeps the requested page in the URL bar
across tab switching although trying to reload the page has no effect :-(
Re comment #36: see comment #3, it was bug #63334
Keywords: nsbeta1
Nav triage team: nsbeta1+/adt3
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3]
This is a problem in Phoenix 0.4 as well, and I run into it about 20-30 times a
day.  I find it so annoying that I'm frequently driven to use internet explorer
when this bug rears its head.
*** Bug 143281 has been marked as a duplicate of this bug. ***
I just noticed an interesting effect I'd not noticed before regarding this bug.
 One of the machines I run mozilla on is technically underpowered for mozilla
(pentium-200mmx overclocked to 225mhz), but because of it's sluggishness, I
noticed this effect.

Clicking on a simple anchor link in an html page results in a delayed reaction
for the urlbar change to the new location.  The tab the page is in starts to
"twirl", the mozilla icon starts to animate, and then a short delay later, the
urlbar contents change.  It looks like the urlbar update to the new url is
delayed until after the page referenced by the url is begun to be retreived from
the server.

This of course is a reasonable action for a simple html anchor link.  I wouldn't
want the urlbar changing to a new url when page retreival for that url fails,
because now the urlbar is out of sync with the actual page being displayed.

However, it looks like this same action is also being applied to new tabs/new
windows, which is where it becomes irritating.  If a new tab or new window is
being opened, there is no url to keep in sync with the displayed page, because
there is no page being displayed yet for that window/tab.  So the urlbar update
for the new tab/new window should occur immediately, instead of being delayed
until page retreival finishes.
For me, this makes tabs nearly unusable (testing with Mozilla
1.3a).

One of my common browsing patterns is to go to a news site
(e.g. slashdot), and open a large number of links in new
tabs.

Particularly as my dns server isn't very reliable this often
leaves me with a lots of tabs of "about:blank" and no way
of retrying the load.

This is my #1 gripe with Mozilla, as tabbed browsing is one
of the key features causing me to use it rather than IE.

Note that as mentioned in the comments above this problem
no longer occurs when using "open in new window", which
displays the url not "about:blank".

The error page work in bug 28586 might help if there were a
way to reload the page. Similarly, this might get included if
the page cloning for bug 18808 were implemented.
Yes, it is terrible there's no way to see which page of the ones you clicked on
didn't load, but I think if you turn on the error pages in from the bug you
mentioned, there is a 'reload' link.
*** Bug 190795 has been marked as a duplicate of this bug. ***
I made a simple fix for this annoying bug:

The patch remembers the URI that started to load in each tab and displays it
instead of about:blank if needed.

This doesn't fix the issue with the reload button not working while the first
page is loaded, but that's what bug 125772 is about.
Attached patch a patch — — Splinter Review 
This bug with 59 votes is identical to bug 104778, which has 82 votes. We could
dupe these two bugs, yet that would be inconvenient for a lot of people. Setting
this bug to block 104778 for now.

A patch has been posted to this bug, but it has not been flagged for review.

I'm not sure that we would want this for Mozilla 1.3 because of the possibility
for regressions. It would be ideal, however, to fix this for 1.3. Nominating.
Blocks: 104778
Flags: blocking1.3b?
Attachment #113352 - Flags: review?
Sorry, not a 1.3b blocker. If there's a safe, small, reviewed and super-reviewed
patch you can try again for 1.3 final.
Flags: blocking1.3b? → blocking1.3b-
*** Bug 193283 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
*** Bug 193436 has been marked as a duplicate of this bug. ***
Target Milestone: --- → mozilla1.4beta
remove JG
Flags: blocking1.4a?
QA Contact: pmac → sairuh
Attachment #113352 - Flags: review? → review?(jaggernaut)
Yoni: I like this approach, but instead of accessing loadingURI from
nsBrowserStatusHandler you could pass it in to onLocationChange from
tabbrowser.xml's updateCurrentBrowser:

http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/bindings/tabbrowser.xml#405

Does this code work with a slow network, where we switch to the new tab before
we actually hit the NETWORK|START section in onStateChange?
Flags: blocking1.4a? → blocking1.4a-
*** Bug 199997 has been marked as a duplicate of this bug. ***
Keywords: dataloss
*** Bug 200853 has been marked as a duplicate of this bug. ***
Flags: blocking1.4b?
Keywords: mozilla1.3
Hello,

hope this testcase can be of any help for people to try
out this bug.

Cheers
Daniel
Comment on attachment 120058 [details]
HTML page with different type of hyperlinks pointing to a non existent domain bugzila.mozilla.org

><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><HTML><HEAD><TITLE>Open Link in new window with URL that fails (timeout, typo, etc.)</TITLE></HEAD>
>
><BODY>
><H2>Testcase: Open Link in new window with URL that fails (timeout, typo, etc.)</H2>
><P>
>	These links should move you to
>	<I>bugzila.mozilla.org</I>. Of course, that host does not
>	exist and accordingly Mozilla issues an error message to this effect.
></P>
><P>
>This is a plain, vanilla <A href="http://bugzila.mozilla.org">link</A>.
></P>
><P>
>This <A href="http://bugzila.mozilla.org" target="_blank">link</A>
>should open a new window using target="_blank".
></P>
><P>
>This <A href="javascript:void 0;" onclick="window.open('http://bugzila.mozilla.org')">link</A>
>should open a new window using javascript onclick handler and window.open(). If 
>javascript is disabled, nothing happens.
></P>
></BODY></HTML>
Comment on attachment 120058 [details]
HTML page with different type of hyperlinks pointing to a non existent domain bugzila.mozilla.org

mh...somehow I can 
not edit this attachment.
I'll add a new one.
Attachment #120058 - Attachment is obsolete: true
*** Bug 201462 has been marked as a duplicate of this bug. ***
*** Bug 201468 has been marked as a duplicate of this bug. ***
Summary: Open in new tab should prefill URL → Open in new tab should prefill URL (may also happen with new window)
Since bug 201468 was marked dupe of this, it should be noted that the patch in
attachment 113352 [details] [diff] [review] does not fix the testcase in comment #59
Flags: blocking1.4?
*** Bug 204335 has been marked as a duplicate of this bug. ***
Flags: blocking1.4b? → blocking1.4b-
Flags: blocking1.4? → blocking1.4-
This bug was re-introduced somewhere after 1.4a.  It is quite annoying since you
are still able to bookmark a blank URL thinking that you saved that page in your
bookmarks.

Please note that if you select the "Load links in the background" check box from
the Tab Browsing Preferences, the URL is not lost.

It looks like someone has already the fix. Do you know when this fix is going to
be put in the latest load ?  THANKS! 


I *ALWAYS* use "Load links in the background", if the conection times out or
something like that, the URL is *ALWAYS* lost whether i use "Load links in the
background" or not.

This bug was here way before 1.4a, and was never fixed in between, despite
having "blocking 1.*" flags on it. Why Asa even bothers setting those flags?...
Like they would work...
*** Bug 204692 has been marked as a duplicate of this bug. ***
*** Bug 207757 has been marked as a duplicate of this bug. ***
Attached patch patch (obsolete) — — Splinter Review 
This patch rides after the patch in bug 104778, though it will apply either
before or after the other patch.  Note that it does not work its magic for new
windows--only new tabs.

Please check that it doesn't break current functionality in weird situations.

You do not need full source to test this; if you don't have a source tree, just
alter the chrome (it's in comm.jar).  The patch is short enough to apply by
hand (one added line, ignoring comments).
This patch rides after the patch in bug 104778, though it will apply either
before or after the other patch.  Note that it does not work its magic for new
windows--only new tabs.

Please check that it doesn't break current functionality in weird situations.

You do not need full source to test this; if you don't have a source tree, just
alter the chrome (it's in comm.jar).  The patch is short enough to apply by
hand (one added line, ignoring comments).
Attachment #125126 - Attachment is obsolete: true
A nice, efficient solution, leveraging the fix for bug 104778. Well done, Tim.
It will be a glorious day when the patches for this bug and 104778 are landed.
It seems we are tantalizingly close. Flag it for review?
No longer blocks: 104778
Depends on: 104778
I've switched the dependencies around (as per Ed Sabol's request in
bug 104778) and moved some of the summary items that more accurately
describe this bug than 104778.
Summary: Open in new tab should prefill URL (may also happen with new window) → Open in new tab should prefill URI in location bar (URL is lost and replaced with "about:blank" when switching tabs if the page fails to load) (may also happen with new window?)
Great, it works. :D
Great Tim :)

But does this also solve the original bug report issue (read and test yourself)?

If it does, lets get this baby a review & superreview
Comment on attachment 120060 [details]
HTML page with different types of hyperlinks pointing to a non existent domain "bugzila.mozilla.org"

Could you explain the intended use of this attachment ?

I tried the 3 links and always get a page reading
[
Bad Gateway
The following error occurred:

The host name was not found during the DNS lookup. Contact your system
administrator if the problem is.not found by retrying the URL.
(DNS_HOST_NOT_FOUND)
Please contact the administrator.
]

While it shows the "should prefill" aspect, as any link will do;
it does not seem to apply to the "lost" aspect, since a (error) page does load
!?

Thanks.
Re comment 65:

asa is not setting ('?') the 'blocking' flags, he's refusing ('-') them (which
were set by someone else).
Have a look at http://bugzilla.mozilla.org/flag-help.html for further info
Tim: this isn't a hack, really. This is exactly what I was thinking of when
coming up with a solution for bug 104778. However, I was thinking about putting
this code in tabbrowser's addTab itself so all callers of it will have the
passed-in URI remembered.
comment 73: I tested it on the test case and it worked for me.

comment 74: It sounds like you have a proxy which handles the DNS resolution.
There are a number of cases where having a proxy changes things unfavorably. 
Mozilla can't tell that the page didn't load because your proxy returned its
error message as a normal page (I can't tell from your comment what status code
it returned).

I will make the comment changes suggested by jag and attach a new patch. Since
we can't yet pre-set review flags when adding attachments, I will have to do
that separately. I appologize in advance to all the people I'm spamming (please
consider visiting your bugzilla preferences; you can avoid most of this spam). =)
Attached patch patch v2 (obsolete) — — Splinter Review 
This one patches addTab in tabbrowser.xml.  I tested it very basically (using
the test case above).
Attachment #125127 - Attachment is obsolete: true
Comment on attachment 125138 [details] [diff] [review]
patch v2

This depends on the patch in bug 104778; if that gets in, this is a very
trivial change (move it into bug 104778's patch if it's more convenient that
way).
Attachment #125138 - Flags: superreview?(sspitzer)
Attachment #125138 - Flags: review?(jaggernaut)
Attachment #125138 - Flags: approval1.4?
Tim, what does this solve exactly?

What does it do?
Note that |this.getBrowserForTab(t)| is |b| in that section of code. I'll just
make this change in 104778, like you suggested.

Thank you for reminding me about this bug, and confirming it was as easy to
implement as I thought it would be.
Re comment 74:

I are right:
That one was
[
+++RESP 525+++
HTTP/1.1 502 Bad Gateway
Date: Sat, 07 Jun 2003 17:09:41 GMT
Content-Length: 333
Content-Type: text/html
Server: NetCache appliance (NetApp/5.3.1R2DEBUG12)
+++CLOSE 525+++
]
and came from my ISP proxy.

After disabling my local (and ISP) proxy(s),
I get the Mozilla error and the empty URL :-)

NB: I'm more used to the timeout case, which "bugs" even with proxy :-<
re comment 83: Have you applied all relevant patches (this one AND the one in
bug 104778)?  And please attach a test case or describe a procedure to reproduce
what you're experiencing.
Re comment 84:

Sorry to have been unclear :-(

I was not testing any patch: only checking (and surprised at the time by) the
testcase.

Comment on attachment 125138 [details] [diff] [review]
patch v2

(Really sorry about the spam :)
Killing review requests. jag is going to merge (a slightly modified but
functionally equivalent version of) this into his patch.
Attachment #125138 - Attachment is obsolete: true
Attachment #125138 - Flags: superreview?(sspitzer)
Attachment #125138 - Flags: review?(jaggernaut)
Attachment #125138 - Flags: approval1.4?
Hmm, it looks like my most recent patch for bug 104778 has stopped this one from
working. Either that or the addTab version has never worked. Did you remove the
contentAreaUtils patch from your tree before testing the addTab one?
Comment on attachment 125138 [details] [diff] [review]
patch v2

>             this.mPanelContainer.appendChild(b);
> 
>+            // pretend the user typed this in (so it shows up before loading)
>+            this.getBrowserForTab(t).userTypedValue = aURI;
You'll find that this.getBrowserForTab(t) is ... b ;-)
Checked in with patch for bug 104778.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → FIXED
would this be fixed on the branch as well, then? or only the trunk?
Mozilla  1.4 build 20030610, my results with the testcase:

- I open the first link in a new tab, and the URL stays there

- I click on the second link, a new window comes up but no URL

- On the third link, the behaviour is the same as the second

Of course, if i open the first 2 links with midle-click, the URL stays there.
okay, i guess this was fixed on the 1.4 branch, given my observations with
2003.06.11 1.4 comm builds (all platforms):

i've got a test page with a bogus link. i open this bogus link in another tab.
the URLbar in the new tab has the [bogus] URL prefilled in there, which would be
expected due to this fix.

the title is remains "Untitled" (which makes sense), but keyboard navigation
(eg, accel+W shortcut to close the tab, or the shortcuts to switch tabs) remains
dead (which was the case before this checkin anyhow). there might be another bug
covering the keyboard nav issues, though.
Keywords: fixed1.4
vrfy'd on the branch.

and the bug i was thinking about wrt keyboard navigation is bug 112337.
Keywords: fixed1.4 → verified1.4
side note about opening links in new windows: this didn't seem to be an issue
before (tested with 6/9-1.4) or after (tested with 6/11-1.4) the checkin. the
[bogus] url was prefilled in the urlbar of the new window.
Yeah, I wonder what it is about the bogus url in urlbar thing...

Oh, wait... It depends on whether we open the window by passing in the url, or
just open a blank window, and then load the url ourselves (some c++, like
clicking a link with target="..." does this, I think).
I just installed 2003061408 and not all the related problems seem to have been
addressed.  Yes, it does now remember the URLs when you switch tabs but it does
not remember the URLs when you want to bookmark any of the tabs that you opened.
The location for that tab is still "about:blank".  You have to hit the Refresh
button and then bookmark it. Also, when you open a new tab (CTRL-T), shouldn't
it clear the location bar ?

Thanks!
Opening a new tab (CTRL+T) should launch the default starting page
(website/bookmark/blank), makes more sense?
I'd much prefer it if it loaded a blank page, as in the current behaviour.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030612]


Re comment 97 and comment 98:

Nothing to do with this bug;
Look at 'Preferences... > Navigator > Display on' !


Re comment 96:
You may look around bug 28586 !?


Re comment 95:
Confirming comment 91. (v1.4rc2)

In which bug will the (simple click) window case be fixed ? Need to reopen the
current bug or bug 63334 or is there yet another bug filed ?

I have another (similar) case, using Bookmark Manager:
Open in New Window or New Tab prefills; but Open (in existing tab/window) does
not :-(
With the testcase (attachment 120060 [details]): simply click on the vanilla link: :-(
Argh, this is still broken for tabs opened as part of *bookmark groups*.  May I
re-open?

Using the 1.4 release
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624)
I note that on a page failure, the URL is indeed remembered correctly
in the address bar.

However, rather unintuitively, pressing F5 or selecting reload
does nothing. To actually attempt to load the page again you need
to select the address bar and hit return.
I still see this in Firebird (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b)
Gecko/20030903 Firebird/0.6.1+). 

Does the checkin for this bug only fix SeaMonkey?
the corresponding firebird bug is bug 203102.
Blocks: 203102
Comment on attachment 113352 [details] [diff] [review]
a patch

Removing obsolete request.
Attachment #113352 - Flags: review?(jag)
Attachment #125127 - Attachment description: patch → patch [== Previous patch posted twice]
Seems to be back with Firefox 0.9.3
If FireFox only, please fill a new bug, which you can make depend on this one if
needed...
Sorry. Seems to be fixed in FF nightly (07.09.2004), but in FF 0.9.3 this bug
exists.
No longer blocks: majorbugs
This bug still exists.

If you click a link and the TCP connection is accepted but no HTTP reply is sent (i.e. Slashdotted), "Connection timed out", the URL bar is empty. It's very annoying because this timeout is long and users are likely to close the originating site and do something else.
As a consequence, reload doesn't work (no URL to reload).

(In reply to comment #108)
> This bug still exists.

Still exists in what?  Seems to work correctly in Seamonkey 1.0a.

For example Ctrl+click this link:

http://www.icarus.com/eda/verilog/

I'm using "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Debian package 1.0.7-1)"
Don't know what version is that in Seamonkey terms.
(In reply to comment #110)
> I'm using "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922
You're using....................................        ^^^^^ 1.7.x, which is about a year old.  Try a Firefox 1.5 beta or SeaMonkey 1.0 alpha, which are based on gecko 1.8.x.


(In reply to comment #111)

Whoops... *puts on brown paper bag*
Product: Core → SeaMonkey
VERIFIED FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.