166999 - Unaccessed URL discarded when switching between tabs

Status: RESOLVED WORKSFORME

(Camino Graveyard :: Tabbed Browsing, defect)

Description

[Brian Lee]

If your in the middle of typing in a URL in a tab but you haven't told the
browser to load the page, and you switch to another tab the url bar is cleared
when you switch back to pervious tab you were on.

1) Launch Chimera
2) goto any page i.e. http://www.google.com
3) open a new tab in that window (you now have 2 tabs one at google and a new
blank tab)
4) in the new tab you just opened type in a url to any page (but don't load the
page, don't hit enter) .
5) switch back to your first tab (google)
6) switch back to the new tab with the url type in but not loaded
7) notice the url bar on the second tab has been cleared

What should happen is that the url you type in the second tab but have not
loaded should still appear in the url bar just as you had left it before you
swtich to the first tab (the one with google)

Comment 1

[Greg K.]

Confirmed using Chimera/2002090505 on 10.1.5. Reassigning to Tabbed Browsing and
revising summary.

Comment 2

[Mike Pinkerton (not reading bugmail)]

personally, i don't agree that it should display the un-accessed url. when i go
back to a tab, i would expect it to have the url of the tab.

threatening to WONTFIX, but would like some other opinions.

Comment 3

[Kathleen :Brade]

I'd be ok with what is proposed here EXCEPT the urlbar is above the tab so I
don't think it fits (to do that).

If anything, I would argue that the url bar shouldn't switch at all when you
switch tabs.  Here is a scenario:
 * load google
 * switch tab
 * url bar still shows google url from previous tab
 * replace google url with "mozilla.org"
 * switch back to the first tab (google)
result: still see the mozilla.org text that you typed

That would be more fitting with the layout of the window.  However, I'm not sure
people will like that either.  I'm happy with the current behavior.

Comment 4

[Brian Lee]

I always thought that the whole purpose of "tabbed" browsing was to reduce
desktop clutter by allowing the users to combine "new windows" into one window
with tabs. If is the case shouldn't each tab have the characteristics of an
independent window (including the url bar)?

Comment 5

[Wincent Colaiuta]

I think the half-typed (unaccessed) URL should be preserved when switching back
to the tab.

Just as a general matter of principle, I don't think it's a good thing to throw
away user input.

The reason why there is debate over this is because the URL bar function is
confused: is it an input area through which the user can command/control the
application (I say yes); or is it a status area which is used to feed
information about the currently displayed location back to the user (in which
case, it's function is starting to blur with that of the status bar, and we
already have one of those).

Personally, I think the half-typed URL should stay in the URL bar, and the
status bar down the bottom should be updated to reflect what's going on. Eg.
instead of saying "Document: Done", it should say something more accurate like
"No page loaded". (Incidentally, I think this should be another bug: that the
status bar says "Document: Done" in cases like this.)

Comment 6

[Bill Bumgarner]

In lieue of filing a separate bug, I would like to add that this problem [not
remembering the URL that should be in the location field] is a bit more
pervasive.  In particular, I often like to bulk-load a slew of URLs or like to
click on URLs when I'm reading a page without a net connection.

If any of the URLs fail to load-- regardless of whether they are in a window or
in a tab-- then the URL that failed is forgotten.

This proves to be extremely annoying in that I have to then figure out (a) what
it was that failed to load during the bulk load or (b) figure out what the heck
I clicked on when my net connection was down.

In general, a User Interface should generally avoid deleting/losing user input
as much as it possibly can.   Nothing is quite so annoying as having a UI lose
what I'm doing because some other event outside of my control-- say, a
connection failure in some other window-- caused the context of the app to
switch and switching back causes data loss.

Comment 7

[FZiegler]

Since pink asked for further comments...

I'm glad that Brian filed this. Please don't wontfix -- rather extend to Mozilla
itself, which has the same problem; and I've long found it very annoying. bbum's
comment conflates two cases:

* URL unaccessed because you didn't hit enter (Brian's original case)
* URL unaccessed because it failed in the background

...but that's OK, because I think both should be fixed. Nothing is more
irritating than

* have a Google search;
* open a few URLs from it in background tabs
  (whether by command-click, or pasting modified URLs in a new tab);
* discover, later, that one of them just says "about:blank".

At that point you'd want to use Google's cache, but -- even assuming you haven't
changed or closed the Google page in the meantime -- it's just too tedious to go
back and find which of a gazillon results it was.

Comment 8

[FZiegler]

I also think that brianlee's point in comment 4 nails it. On a faulty link like
http://apple.org/whatever/ , there is no reason why "open in new tab" should
lose info that "open in new window" doesn't.

Comment 9

[FZiegler]

hmmm... for a better example which *does* give different results in "new tab" vs
"new page", try http://mmoozziillaa.org .

Comment 10

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 11

[Mike Pinkerton (not reading bugmail)]

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

Comment 12

[FZiegler]

Will a fix to bug 104778 (120 votes...) solve this one -- in which case it
should probably be marked a dupe or dependent -- or is the Camino case independent?

Comment 13

[Bill Bumgarner]

Given the way that Cocoa's text editing works, fixing this will be very specific to Camino.Specifically, you will need to catch the tabWillDeactivate (or whatever the NSTabView notification is) and check to see if the text field is being edited.  If so, the current value will have to be grabbed from the field editor-- not from the text field itself.

Comment 14

[dan.m]

I do not see the reporter's described behavior on Build ID: 2003082702.

Instead, what happens when I open a new window and follow the procedure, is that
the URL I typed (but did nothing with) remains in the URL bar no matter which
tab I switch to. IOW, it sticks across tabs rather than changing to reflect the
particular URL I am viewing.

Separate bug?

Comment 15

[Brian Lee]

That wasn't the behavior I was expecting from the fix if they did indeed fix it. Like I said in 
comment 4, If you open a new tab it should be treated as a new window so if say your first tab of 2 
had say http://www.apple.com loaded and you switch to the second tab type in http://
www.macnn.com but don't load macnn (don't press enter in the url bar after typing macnn 
address) swtich back to the first tab, the first tab should still say http://www.apple.com and if you 
switch back to the second tab it should say http://www.macnn.com but the macnn page should 
not be loaded because you did not press enter after entering the macnn address

Comment 16

[Oakland Raiders]

Should this REALLY be a "Camino" bug?  The same thing happens in "Firebird" for
Windows... (Thats how I found it in the first place).

And this should DEFINATELY be fixed.  Here is another example why:

Say you are using a webmail system that wraps text automatically.  URLs then
will get wrapped and split up if they are too long.  So you have to piece the
URL together, as the browser will only recognize the first line as a URL.

So you copy the "link", go to a new tab - put it in the URL bar, then go back to
the first tab to copy the second line - or remaining part, and you tab back to
your new tab - and the first half of the link is gone.  Currently the only work
around is to open a text editor to "rebuild" the link, then open it in Mozilla.  

A better option is to fix this bug.  I will test when I get home, but I would
wager that this occurs in more than just Camino(Mac) and Firebird(Windows).

Comment 17

[Jasper]

I agree that saving the partial not submitted url should be saved for the user.
Apps should always save user input untill further notice, never should it just
trash it.

Wanted behaviour
- save the url in the addres toolbar item.
- keep the tab title to say "untitled..." since nothing ever loaded.
- when swicthing back to this tab make sure focus is on the addres toolbar item.

I'm removing it from the critical list since it's not crashing Camino or anuthing.

Comment 18

[Ludovic Hirlimann [:Usul]]

with build 2004090408 (v0.8+)