Closed Bug 104778 Opened 23 years ago Closed 21 years ago

URI written in location bars doesn't persist tab/window switching (incomplete url is forgotten upon tab switching)

Categories

(SeaMonkey :: Tabbed Browser, defect)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.4beta

People

(Reporter: aha, Assigned: jag+mozilla)

References

Details

(Keywords: dataloss, Whiteboard: [adt2][Hixie-P0][MB][ETA: 2003-06-06])

Attachments

(3 files, 9 obsolete files)

Addresses Neil's comments
23.39 KB, patch
janv
: review+
bugs
: superreview+
Details | Diff | Splinter Review
Same patch, branch style.
10.28 KB, patch
asa
: approval1.4+
Details | Diff | Splinter Review
Also remember what the user tried to load, v1.2
7.70 KB, patch
neil
: review+
bryner
: superreview+
asa
: approval1.4+
Details | Diff | Splinter Review 
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.5+) Gecko/20011014-trunk

Repro:
1. go to any URL (for example http://www.mozilla.org/ )
2. when page is loaded, write any URL/text to location bar, but don't enter it
   (for example 'keyboard')
3. open new tab using Ctrl+T
4. return on previous tab (with loaded www.mozilla.org)

Actual result:
There are back URL of page (http://www.mozilla.org/), written text (keyboard) is
lost.

Expected result:
URL/text written in location bar of first tab window still persist.
i'm not sure, but i think this is more of an enhancement rather than a bug.
however, many other people may disagree.
For me it's bug - I know, what I'm writting and why I'm writting it. When I
wrote something on location bar and it's deleted by non-editing action, it's
IMHO bug.

URL of current page is available via Page Info (but also bug 55713) or via page
reload.
This sounds like a bug to me.

Confirmed linux 0.9.5 and my trunk build from a couple days ago.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
Bug for me, too.
Situation: A long, line-wrapped URL (often seen in web-forums or <pre>-texts)
needs to be copy'n'pasted to a new tabs address bar: mark first part of url,
change tabs, paste, go back, mark rest, back to new tab --> first parts is gone
*** Bug 112284 has been marked as a duplicate of this bug. ***
It's a dataloss.
Keywords: dataloss
Keywords: dataloss
QA Contact: blakeross → sairuh
jrgm@netscape.com, can I ask why did you removed the dataloss keyword?

I loosed about 10 times URLs I typed in and I must again search for them... For
me it is a critical dataloss that takes my time. :(
Keywords: dataloss, nsbeta1
Hardware: PC → All
*** Bug 117100 has been marked as a duplicate of this bug. ***
*** Bug 116733 has been marked as a duplicate of this bug. ***
Reassigning to new component owner.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
*** Bug 125673 has been marked as a duplicate of this bug. ***
Whenever a fix is made, please make sure hitting 'Escape' in the URL bar will
bring back the current URL (ie, what's currently displayed).
nsbeta1- per ADT triage team
Keywords: nsbeta1 → nsbeta1-
Present in 0.9.8 and 2002030406 on Linux/x86.  I would classify it as a bug as
well, and an oft-hit one for tab users.

110128 looks to be a duplicate.
*** Bug 110128 has been marked as a duplicate of this bug. ***
*** Bug 129320 has been marked as a duplicate of this bug. ***
*** Bug 130060 has been marked as a duplicate of this bug. ***
*** Bug 130444 has been marked as a duplicate of this bug. ***
I find the case where you type a URL, don't press return, and revisit the tab
later less annoying than the following case, where you tend to work with 10+
tabs open - and have a bad memory ;-)

1) you type a URL
2) it's slow to load
3) ...so you visit another tab in the meantime
4) you notice the original tab failed to load
5) you've forgotten what it was - it's just blank

This bug bugs me a lot.

*** Bug 135188 has been marked as a duplicate of this bug. ***
Summary: URL written in location bars didn't persist tab switching → URL written in location bars didn't persist tab switching (empty tab says "about:blank")
Whiteboard: [Hixie-P0]
*** Bug 111874 has been marked as a duplicate of this bug. ***
*** Bug 138203 has been marked as a duplicate of this bug. ***
Can someone please change the summary to better reflect the undesirable behavior?
Summary: URL written in location bars didn't persist tab switching (empty tab says "about:blank") → URL written in location bars don't persist tab switching (empty tab says "about:blank")
trudelle, if you prepared a songlist for a cd player that allowed you to insert 
multiple disks and select playlists per disks, would you as an end user get 
upset when your list is forgotten if you don't select commit before switching 
disks?
Keywords: relnote
Summary: URL written in location bars don't persist tab switching (empty tab says "about:blank") → user entered text in location bar that hasn't been accepted (enter/go) is lost on tab switch
I don't think this description is accurate.  The URL is also lost if the user 
switches tabs before the page has loaded (even after "committing" the URL).

Steps to reproduce:
1. open a new tab
2. enter a location in the location bar, press enter
3. quickly activate a different tab, then return to the new tab

about:blank will also appear there.

Surely this is the same bug, and is highly undesirable.

Suggest new summary that includes this similar problem such as:
"URL is lost when switching tabs if the page hasn't been loaded"
Summary: user entered text in location bar that hasn't been accepted (enter/go) is lost on tab switch → URI written in location bars don't persist tab switching (empty tab says "about:blank") (URL is lost when switching tabs if the page hasn't been loaded)
Whiteboard: [Hixie-P0] → [Hixie-P0][MB]
*** Bug 138805 has been marked as a duplicate of this bug. ***
timeless: I have been burned by players wiping out my playlist when I open a
single song instead of adding it, but I'm not sure how relevant such a scenario
is to the defect reported here.  This is a bug, the Navigator triage team just
does not require it to be fixed for MachV. YMMV
*** Bug 139399 has been marked as a duplicate of this bug. ***
This is still one of the most annoying things in the pre-1.0 builds.
I middle-click a link on a somewhat busy site (slashdot.org in the
Central Daylight Time morning), wait a moment, get "Connection refused",
and I can't refresh because it's about:blank .
see bug 142298
First of all, the summary of this bug isn't very clear.

But the main reason for this bug issue is that 'userTyped.value' in
nsBrowserStatusHandler.js isn't set correctly after typing an url in the url
bar, so it get's wiped out. 

We need to look at userTyped: to fix this bugs main issue, because I strongly
belief that something isn't going as it was planned. I keep getting false back,
and that's wrong!

BTW: the patch for bug 142298 will fix the 'about:blank' url bar issue for tab
switching only!


Well, this looks intended to me (after taking a look at bug 109650):

<snap>
get value() {
       if (this.browser != getBrowser().mCurrentBrowser) {
         this._value = false;
</snap>

'userTyped.value' is set to false here, if you switch tabs. Maybe we can/should
change it a bit so the typed url's won't get overwritten.
What exactly is this bug report for?

1. loosing typed text in the url bar, after switching tabs
2. url gets filed with 'about:blank', after switching tabs
3. URL is lost, after switching tabs, if the page hasn't been fully loaded

Please make up your mind, only one bug item per bug report, or has that changed?
FYI: I have a working concept to fix the #1 issue for this bug. I now need to
remove the favicon, after typing text in the url field, and clean things up a bit.
Attached patch diff -u (obsolete) — — Splinter Review 
This patch will fix issue #1 of this bug, have fun.
Keywords: patch, review
*** Bug 142298 has been marked as a duplicate of this bug. ***
The patch will also fix issue #2 (bug 142298) so that has been marked as a dup
of this bug.
Comment on attachment 82403 [details] [diff] [review]
diff -u

looks good, r=morten@nilsen.com
Attachment #82403 - Flags: review+
Keywords: mozilla1.0
*** Bug 142972 has been marked as a duplicate of this bug. ***
*** Bug 143537 has been marked as a duplicate of this bug. ***
*** Bug 144452 has been marked as a duplicate of this bug. ***
*** Bug 144721 has been marked as a duplicate of this bug. ***
Will this fix also fix 111086?  That's currently (falsely) marked as WORKSFORME,
but may be related to this.
No, not yet. However, I will try to solve this issue also. 

FYI: I reopened that other bug :)
*** Bug 148116 has been marked as a duplicate of this bug. ***
*** Bug 148620 has been marked as a duplicate of this bug. ***
*** Bug 138805 has been marked as a duplicate of this bug. ***
*** Bug 152253 has been marked as a duplicate of this bug. ***
Blocks: 1.1b
Im having this problem too, running 1.1a Linux here.
I dont think we should waste time discussing whether this is a bug or not.
If a user type something on a widget, of any kind of interface, and need to go
to other TAB of the same interface to check for some information, to be able to
complete what he was typing, and when he comes back the typed stuff is gone,
this makes user MAD! Lets fix it dudes :) So, url bar content persistence on tab
navigation is a must, even when typed content wasn't commit.
*** Bug 155778 has been marked as a duplicate of this bug. ***
*** Bug 156842 has been marked as a duplicate of this bug. ***
Blocks: 1.1
No longer blocks: 1.1b
Blocks: 123569
Keywords: mozilla1.0, nsbeta1- → mozilla1.1, nsbeta1
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [Hixie-P0][MB] → [Hixie-P0][MB][adt2]
Comment on attachment 82403 [details] [diff] [review]
diff -u

This patch makes userTyped.browser and userTyped._value irrelevant, but doesn't
remove the (now) dead code.

It mixes in a change that makes all about:blank, including user typed ones,
never show in the url bar (talk to mpt about why that's bad), something that
shouldn't really be in this patch.

There are two functional problems with this patch.

1) you have two tabs open, at some point you've typed a partial url in the
first tab, you're now on the second tab (because you couldn't remember the rest
and decided to look it up using google) and drag the link you've found to the
first tab to load that page there. The first tab will not have its urlbarTyped
reset, so when you switch back to that tab you get the text you've typed
instead of the url for the page you've just loaded.

2) type something in the urlbar, notice how the proxy icon (that bookmark icon
left of the urlbar) becomes disabled. Switch to another tab, switch back, and
hey presto, it's enabled (or replaced with the site's "favicon"). If you now
drag the proxy and drop it on your personal toolbar you'll get the title of the
site you're currently viewing with the text you typed for the url, instead of
the page's real url.
Attachment #82403 - Flags: needs-work+
Issue 3 of comment 33 is exactly bug 103720.
No longer blocks: 1.1
No longer blocks: 123569
*** Bug 162661 has been marked as a duplicate of this bug. ***
What's the state of this bug? I too find it very annoying, esp. in cases like in
comment #4. A major usability bug, IMHO.
*** Bug 165631 has been marked as a duplicate of this bug. ***
I have the same problem that comment #29

When I middle click to open new tabs, if some page does not load, you won't know
its address.
Summary: URI written in location bars don't persist tab switching (empty tab says "about:blank") (URL is lost when switching tabs if the page hasn't been loaded) → URI written in location bars don't persist tab switching (empty tab says "about:blank") (URL is lost when switching tabs if the page hasn't been loaded) (incomplete url is forgotten upon tab switching)
Keywords: mozilla1.1 → mozilla1.2
*** Bug 171092 has been marked as a duplicate of this bug. ***
*** Bug 146586 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
Attached patch First try (obsolete) — — Splinter Review 

    
    

    
  
*** Bug 173386 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → pmac

    
  
Keywords: mozilla1.3

    
  
Summary: URI written in location bars don't persist tab switching (empty tab says "about:blank") (URL is lost when switching tabs if the page hasn't been loaded) (incomplete url is forgotten upon tab switching) → URI written in location bars doesn't persist tab switching (empty tab says "about:blank") (URL is lost when switching tabs if the page hasn't been loaded) (incomplete url is forgotten upon tab switching)

    
    

    
  
Are we sure the summary's long enough now?

    
    

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

    
    

    
  
Bug 159537 is very simmilar, but does not involve tabs.

    
    

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

    
    

    
  
Even though the Neil's patch definitly needs work, I am quite sure bug 159537 is
a duplicate, updating summary to also include window (Re comment 63: No)
Summary: URI written in location bars doesn't persist tab switching (empty tab says "about:blank") (URL is lost when switching tabs if the page hasn't been loaded) (incomplete url is forgotten upon tab switching) → URI written in location bars doesn't persist tab/window switching (empty tab says "about:blank") (URL is lost when switching tabs if the page hasn't been loaded) (incomplete url is forgotten upon tab switching)

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
  
Whiteboard: [Hixie-P0][MB][adt2] → [adt2][Hixie-P0][MB]

    
    

    
  
I have a hard time believing how many people are using their votes on this bug
when Mozilla doesn't yet even have an adequate Bookmark Find feature like
Netscape 4.x had (bug 95748).  You know, people, if you see a bookmark that
isn't linked but is instead just plain text, all you have to do is highlight it
and drag it to an existing tab, or the tab bar to create a new tab.  It isn't
clear to me that there'd be many instances of needing to type it manually while
switching back and forth between tabs.

    
    

    
  
Please note comment 4:

Situation: A long, line-wrapped URL (often seen in web-forums or <pre>-texts)
needs to be copy'n'pasted to a new tabs address bar: mark first part of url,
change tabs, paste, go back, mark rest, back to new tab --> first parts is gone

You should use the following preference in prefs.js:
user_pref("editor.singleLine.pasteNewlines", 3);

By doing this, you can copy and paste multi-line URLs into the URL bar.

It's true this should be fixed but there's 69 votes on this thing which
certainly is a lot if you notice other bugs!

    
    

    
  
Another situation:

Consider middle-clicking a link to open in a new tab (a fantastic feature which
I use all the time).  However, the site is busy (perhaps slashdotted), so the
request fails.  But because the URL has been lost, I can't just switch to the
tab and hit "reload", and must instead find the link again.

    
    

    
  
Re comment:74

It would help if you actually read the bug-report. You appear not to have read
it. For a summary of the important points (if you cannot be bothered to read
everything) please go back and read comments: 19, 25, 49 (in addition to 4).
Then please re-consider your opinion in light of the actual problems being
described, and in light of the bugs that have been marked as dupes of this one.

An opinion of "I think there's another bug that annoys me more than this one
does; therefore you lot are all wrong/foolish/wasting time" really isn't
helpful. The point of a shared bug-tracking system is to catch and fix all the
bugs, not just the ones that are annoying you, one person, personally.

    
    

    
  
re: 75

Or, similar effect but perhaps much more frequently occurring, as cited in at
least one of the many bugs duped to this one (because I was one of the
reporters!) on a dialup connection, when your connection dies, you frequently
are left with a large number of open tabs all saying "Loading..." which haven't
loaded enough of the page/image to get around to making the new URL "permanent"
in the address bar for that tab.

Seeing as dialup-users generally have to wait so long for each page to load that
it is more useful to them to have lots of tabs/windows open (so that the load
time is amortized over the time they are just reading the pages that have
already loaded), this is a *very* annoying problem.

    
  
Keywords: mozilla1.2

    
    

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

    
    

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

    
    

    
  
does the work on bug 28586 help with this?

    
    

    
  
No. If you enable error pages, you still get the same problem.

    
    

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

    
    

    
  
Adding myself to CC.

    
    

    
  
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.
Severity: normal → critical

    
    

    
  
Shuehan has graciously agreed to take this bug from me.

    
    

    
  
Right.
Assignee: jaggernaut → shliang

    
  

        Attachment #101396 -
        Flags: review?(shliang)

    
    

    
  
And taking it back.
Assignee: shliang → jaggernaut

    
  
Depends on: 103720

    
    

    
  
#75 is what bugs me the most. I really hate it, all those open tabs become
about:blank, untitled, and I have to gather them all again. It's the exact same
feeling as if mozilla had crashed, you have just lost your work.

Please fix this...

    
    

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

    
    

    
  
I've forgotton to revisit this patch, but I do know what jag was going on about,
and I think I can fix it by adding

if (window.XULBrowserWindow.userTyped.value)
  aState = "invalid";

in the SetPageProxyState function.

    
    

    
  
See also the patch posted to this in bug 103720.

    
    

    
  
Perhaps this bug needs resummarizing so that it only covers the issue of an
incomplete URL, rather than a URL that failed to load (bug 103720).

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Another go (obsolete)
        — 
          — Splinter Review
      

    


  
This is still only to address the issue of losing the url as you are typing it.

        Attachment #101396 -
        Attachment is obsolete: true

    
    

    
  
Neil, does anything more need to be addressed? If not, please flag your patch
for review. I'd love to see this in 1.3 final. 

How does your patch compare to the patch for bug 103720? Would you say that they
complement each other or are they mutually exclusive?

    
  

        Attachment #101396 -
        Flags: review?(shliang)

    
  

        Attachment #114446 -
        Flags: review?(shliang)

    
  
Target Milestone: mozilla1.0.1 → mozilla1.4beta

    
  
Flags: blocking1.4a?
QA Contact: pmac → sairuh

    
    

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

    
    

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

    
    

    
  
Neil: I was thinking about a different approach to deal with all these issues,
but I need to work it out a little more:

Start with storing the text you've typed on the <tab> (or the <browser>) when
you switch away from the current tab (browser.typedText?).

When you switch to a tab (e.g. from nsBrowserStatusHandler::onLocationChange),
see if the <tab>/<browser> has the urlbar text (browser.typedText), if so, take
that and remove it, otherwise take the location passed in

You'll still need to keep track of when the user typed, which you may need to
remember per tab. This flag will need to be unset when a pageload starts, and
looked at before the url is set in the urlbar from onLocationChange (so we don't
overwrite anything the user started typing between pageload start and pageload
end). [note: potential weird timing interaction between pageloads and tab switches?]

Then perhaps we could (ab)use browser.typedText to store the url for "open link
in new tab" so it'll automatically show up when switching to the tab.

    
  
Flags: blocking1.4a? → blocking1.4a-

    
    

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

    
    

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

    
    

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

    
    

    
  
This is a very annoying thing indeed.
It also happens when you enter a very large address, but with a
tiny typo.. If you go to another tab and return, you have to retype
the entire thing! In this case IE still outperforms mozilla :P

    
    

    
  
Except that IE...

DOESN'T HAVE TABS!

    
  
Flags: blocking1.4b?
Keywords: mozilla1.3

    
    

    
  
This bug have a patch and a review request... for about 2 months now (and this
is a really painfull for users, as I can see on forums).

I'll post a message to shliang@netscape.com.

    
    

    
  
This bug also has > 100 Votes, It exist 21 bugs with more than 100 votes, I
think this bug and the other need to be considered with more priority than others.

    
    

    
  
thank you for volunteering, please fix it asap.
Assignee: jaggernaut → NetVicious

    
    

    
  
Well, sorry If my last message was a little offensive, I only said the bugs with
more votes should be more painfull for users and should have more priority than
others, I don't force anybody to fix it. I know Mozilla it's open source and
it's maked in the free time of a lot of dedicated programmers.

I'm spanish so I could write something bad.
Assignee: NetVicious → jaggernaut

    
    

    
  
Regarding the last few comments. This bug should not, and will not, have a
higher priority than bugs that cause Mozilla (or the Operating System) to crash.
Bugs like Bug #200965, Bug #200914, Bug #200878, Bug #200801, etc, etc.

This bug is important (just look at the number of votes), and I think it's a
pain as well. However, those few people who have time and a deep understanding
of the code, are busy trying to stop Mozilla from crashing. Others need to step
in to fix bugs like this one. And no, I'm not offering as I'm busy on other
bugs, and helping out whenever I can.

    
    

    
  
Unfortunately, David, there are many conflicting views about what's important.
Some of the bugs you've quoted affect tiny numbers of users in unusual
situations (eg. 200914 being Flash on a particular site under Solaris). Bugs
like this one here affect every user of Mozilla and should have been fixed
before things like Flash support even existed.

Tabs should act like any other form of separate browser window. They currently
don't. Simple as that. What's more, inherently bad design that should have been
fixed years ago and is left in place like this just guarantees that ordinary
users will keep using IE, because Mozilla looks like a school project that's
never been properly thought out. I'm not saying that to upset anyone -- quite
the opposite, it's just a crying shame that Mozilla is so fantastic in some ways
and such an unmitigated shambles in others.

    
    

    
  
<QAIgnore>
Cool it, guys.  The order the bugs actually get fixed in is inescapably
determined by the people fixing them.  If you want to indicate that the
bug is important to you, vote for it; the developers are aware of the 
number of votes and can take that into account, but they are not, cannot 
be, and will not be the only consideration.  If they were, we'd have had 
PGP support before the browser was even usable.  And relax:  this is 
already marked as dataloss, and that gets it on more radars than any
amount of whining about votes can do.
</QAIgnore>

    
    

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

    
    

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

    
    

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

    
    

    
  
Hi,

I don't think that bug 201468 is related to this one.

Cheers
Daniel Kabs

Germany


    
    

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

    
  
Flags: blocking1.4?

    
  
Flags: blocking1.4b? → blocking1.4b-

    
  
Flags: blocking1.4? → blocking1.4+

    
    

    
  
The first part of this bug's summary is bug #103720 (sorry I dunno how to 
link), and is NOT what the reporter was concerned about. I believe it should be 
removed.

    
    

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

    
    

    
  
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4b) Gecko/20030507]

(I searched this bug for "window" and did not find it written, so:)

The first Summary part reads "URI written in location bars doesn't persist
tab/window switching".

In my case:
*New Tab (Ctrl-T) is broken.
 (I confirm that is has been for very long/allways.)
*New Window (Ctrl-N) seems to keep the typed text (now).
 (Except for this test, I am not used to use new windows.)


    
    

    
  
att: Comment #117

you should *really* use a newer build. CTRL + T is NOT "broken", the
feature/shortcut itself works fine, but it does not keep the typed text as is
requested in this bug.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030519 Mozilla
Firebird/0.6

    
    

    
  
Re comment 118:

Sorry, I did *not* mean that Ctrl-T feature was broken :-(
What I wanted to write is that this bug occurs with Ctrl-T (and not Ctrl-N) !


    
    

    
  
This bug has absolutely no relation to Ctrl-T.
This bug is about a links which are being opened in new window/tab by link
context menu or Ctrl-Click.

    
    

    
  
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507]

Re comment 120:

*Sorry again: I just thought that Ctrl-T was one way (among others) to get a Tab
switch effect.
Please read my comments again and focus on the Tab/Window change effect, not on
the keyboard mean(s) I used: it's the same with mouse click for example.

*"This bug is about a links which are being opened in new window/tab by link
context menu or Ctrl-Click."

On that one, you may be mistaken: the summary is very clear that this bug is
about typing text in the URL bar; nothing to do with actually loading anything.


    
    

    
  
"This bug is about a links which are being opened in new window/tab by link
context menu or Ctrl-Click."

That description rather fits bug 103720.

    
    

    
  
Oh, sorry, sorry.....

    
    

    
  
Branch is getting nearer, and this patch is needing review for a week now.
previous patch had a positive review, though needing work. Are 151 votes too much?

    
    

    
  
Re comment 124:

I would agree;

But I notice something which may be odd:
The current bug has blocking1.4+,
while bug 103720 (with 107 votes now), on which it depends, has blocking1.4-.

(I don't know more than this.)


    
    

    
  
Comment on attachment 114446 [details] [diff] [review]
Another go

So Neil's patch, if I read it correctly, will bring us up to par with Safari in
that we keep what the user has typed when we switch tabs (instead of seeing the
URI for the selected tab). Maybe that's enough to fix this bug, though I was
thinking of something smarter where we remember what the user typed, show the
url for the selected tab, and when switching back restore what the user typed.
I'm willing to take this patch for now (updated to the trunk as need be) and do
the better thing later on.

        Attachment #114446 -
        Flags: superreview+

    
    

    
  
That would be not only not helpful for me, but downright unhelpful.  I certainly
don't want to type a partial url into one tab (tab a), go to another tab (tab b)
(generally to get more info to construct the url in tab a) and have tab b's URL
overwritten with my partial typing for tab a.

I'm trying to get tab a to keep it's partial typing, not to keep it in the
foreground tab wherever that may be.

    
    

    
  
"So Neil's patch, if I read it correctly, will bring us up to par with Safari 
in that we keep what the user has typed when we switch tabs (instead of 
seeing the URI for the selected tab)"

That has nothing to do with this bug. That is not "up to par". That is not
right. We don't want that. We want the typed URL that applies to the tab to not
be deleted so that when you return to the tab, what you typed is still there. 

In comment 0, it clearly states that this bug is about preserving what is typed
in the URL bar for the particular tab, even when the tab is switched. It has
nothing to do with universaling the URL bar for all tabs.

Please do NOT check the patch in. It would create data loss. If you insist on
redefining this bug, then at least create a pref to turn off such annoying
misbehavior.

    
    

    
  
I agree with the last two comments, I wouldn't want the URI to be universal, I
think the URI bar should remain per-tab.

Whatever happens, don't add a pref for this. That would be worse than whatever
solution we pick.

    
    

    
  
I'll agree with the previous two statements.  A patch to "retain" a partial URL
in a different tab is not what this bug is about and would, in fact, (I believe)
just make things worse.  At best it would be substituting one form of dataloss
for another.

    
    

    
  
So now we have to vote against bad fixes? Why is it so hard to correct this bug,
I don't get it. Please don't make it worse and loose time with an incorrect
solution.

    
    

    
  
jag: so given the above, the way to fix this is similar to bug 103720 in which
each browser needs to remember the URL as it is typed (attempted for 103720)?

    
    

    
  
Neil: It seems likely that the same fix could cater for both bugs, yeah. One
thing, though: The text entered by the user should be cancellable (hit ESC and
it should revert to the tab's actual URI) whereas the URI for pages that have
failed to load should not be (start typing and hit ESC and it should revert to
that URI, in fact).

And all this should work with that error-pages-should-use-the-content-area-not-a-
dialog bug

    
    

    
  
In case it's not already clear how serious this bug is, I lose up to 15 minutes
a day ONLY because of this single bug. Open up a lot of tabs, and if you're
unlucky the internet connection disconnects, and you have to go back to your
history and slowly, laboriously, retrace your steps through all the pages you
had been to, re-read all the links, work out which ones you were trying to
visit, etc.

Perhaps this wouldn't be so bad if Mozilla had a more advanced UI (e.g if
closing of tabs were an "undoable" action, in which case I could just "unclose"
the tabs I had ctrl-clicked from, and somewhat reduce the time wasted) - but I'm
not asking for something radical or boundary-pushing - I just would appreciate a
working browser that didn't waste many hours of my time.

    
    

    
  
Answering to #134 adam.

Try this addon for undo or remove "Close All Tabs" link
http://white.sakura.ne.jp/~piro/xul/_tabextensions.en.html

    
    

    
  
Re: Comment #134

Read the summary of this bug... it's not about tabs loosing their URI if the
connection dies or the target server is down... It's about you loose the URI
when switching between the tabs, and the URI has not been "entered"..


While I share your annoyance with the behavior you describe, it is not really
part of this bug  (BTW, 15 min. is a *very long* time?)

    
    

    
  
Adam, you're talking about bug
http://bugzilla.mozilla.org/show_bug.cgi?id=103720, and chances are, people that
what this bug fixed, want that fixed as well. IMO, in this moment, taking out
crashes, there is nothing more worse than that bug on mozilla, it really is annoying

Vote for it. 

    
    

    
  
Adam, you're talking about bug
http://bugzilla.mozilla.org/show_bug.cgi?id=103720, and chances are, people that
what this bug fixed, want that fixed as well. IMO, in this moment, taking out
crashes, there is nothing more worse than that bug on mozilla, it really is annoying

Vote for it. 

    
    

    
  
I'm sorry. When I get problems, its usually with both bugs at once. Once the
OTHER bug has occurred, you now have a bunch of about:blank tabs, so sometimes
(if you can) you copy-paste to fill them up. If I understand correctly, you then
often get hit by THIS bug as well...

...because you copy-pasted a new URL into a tab, switched to the next one,
repeated, etc. But when you go back to an earlier tab, it still shows
about:blank, and your text has been thrown away (because of this bug), and
perhaps the original reason the page didn't load (examples quoted in the other
bug) causes it to fail to load on this, the second attempt.

Is this a correct summary? Apologies if I'm completely off-track here (and sorry
for confusing the two bugs!)

PS Yes, it is a long time - but I have to do lots of research, on a slow dialup,
and that means 5-30 mozilla windows open, each with up to 10 tabs. Not as
chaotic as it sounds - 5-10 virtual desktops with typically 0-5 mozilla windows
on each. I would have fewer windows (only one per desktop), more tabs, except
mozilla crashes LOTS if you routinely have lots of tabs open (and many other
bugs specific to lots of open tabs. Sigh.). 

    
    

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

    
    

    
  
Following the status of the bug is not worth the spam. Not for a simple bug.

    
    

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

    
    

    
  
We need to fix two things here: typing in the URL bar is lost (note: the URLbar
typing should be tied to the tab (remembered per-tab), not persist across tab
switches, but that's just my opinion), AND (even more important IMHO) we need to
fix the "about:blank" location display when a new tab fails to load.  Quite
probably the same fix would handle both, especially if we do the per-tab values
for the URLbar.


    
  
Blocks: 207655

    
    

    
  
There's lots of discussion here.  If people believe that it would be better to
fix this by neil's patch:
http://bugzilla.mozilla.org/attachment.cgi?id=114446&action=view
which makes typing persist when you switch tabs, then we may be able to get that
in since it's already sr=jag.  I'm not sure, Ian, if someone would have time to
do the Esc-restores-url addition or not.

Some people here believe that Neil's patch would be a step backward.  If so, we
can leave this the way it is (and leave 103720 the way it is, since that's
already -'d).

If you want this patch for 1.4, make a case.  If you want Esc support in it, add
it now to the patch.

    
  
Whiteboard: [adt2][Hixie-P0][MB] → [adt2][Hixie-P0][MB][ETA: 2003-06-06]

    
    

    
  
I firmly believe the text typed into the URI bar should be remembered on a
per-tab basis. The patch as it currently is written should not be accepted.

    
    

    
  
I agree with Ed.  It's quite simple really:  You don't expect anything
else on a tab to change when you switch tabs do you?  Would you like it
if all the images of one tab migrated to another?  Of course not!  How about
fonts from one tab invading fonts from another tab?  Ridiculous!
Everything on one tab should remain as is no matter what one does elsewhere.
Any other behavior makes mozilla inconsistent.

    
    

    
  
With all due respect to Neil (and many thanks for his work in creating a patch),
I have to say that it doesn't solve the problem addressed by this bug. However,
what the patch does do, IMHO, is create a good platform for further work to get
this bug fixed.

So, I vote that this patch doesn't get checked in as I believe what it will do
to tabbed browsing would be a big backward step.

    
  
Status: NEW → ASSIGNED

    
    

    
  


  

        Attachment #82403 -
        Attachment is obsolete: true

        Attachment #114446 -
        Attachment is obsolete: true

    
    

    
  


  

    
    

    
  


  

        Attachment #125080 -
        Attachment is obsolete: true

        Attachment #125081 -
        Attachment is obsolete: true

    
  

        Attachment #125085 -
        Flags: superreview?(sspitzer)

        Attachment #125085 -
        Flags: review?(neil.parkwaycc.co.uk)

    
    

    
  
Great, that certainly seems to work (moz1.4-cvs, Linux/x86).


    
  

        Attachment #125084 -
        Flags: superreview?(sspitzer)

        Attachment #125084 -
        Flags: review?(neil.parkwaycc.co.uk)

    
    

    
  
Ah -- it doesn't seem to address one aspect of this bug (according to the
summary at least), the 'URL is lost when switching tabs if the page hasn't been
loaded' part.

(If I enter a URL and then switch tabs away and back again before the page
starts to load [say the server is slow and/or will eventually time-out], the URL
bar is blank when I switch back again.)


    
    

    
  
Can you (testers) comment out line 382 of nsBrowserStatusHandler.js (after
applying the latest patch) and tell me if that breaks anything and if that fixes
the last-mentioned problem?  The line is "getBrowser().userTypedValue = null;"
in startDocumentLoad.


    
    

    
  
Nah, that didn't help.


    
    

    
  
Re comment 153:

Could this aspect of the bug be a side-effect/consequence of bug 103720, which
would be fixed there rather than here ?


    
    

    
  
Ah sure, yup, could be.  In which case it should be removed from the summary for
this bug, otherwise that bug is a dup of this one...

    
    

    
  
Re comment 157:

I'll let jag (or sairuh or ...) answer that.

From my understanding of the current summary various aspects:

[URI written in location bars doesn't persist tab/window switching]
This bug !
See also comment 117: does anyone has a "bug" testcase for the 'window' part ??

[(incomplete url is forgotten upon tab switching)]
Almost identical to previous aspect and could be merged with it !?

[(empty tab says "about:blank")]
I'm lazy to reread the comments about it: is it this bug, bug 103720 or yet
another one ?

[(URL is lost when switching tabs if the page hasn't been loaded)]
This one might be bug 103720 rather than this one !?


    
    

    
  
I don't understand how [empty tab says "about:blank"] is a bug? If anything it
is related to bug 103720.

Bug 103720 is actually a bug describing the loss of URI in location bar if the
targeted URI is dead and opened in a new tab:
<from bug 103720>
"When you open a URL in a new tab and the loading fails,
you are left with a untitled tab with no URI in the new tab." 
</from bug 103720>

This bug however only seem to be about the fact that URI only *written* in
location bars doesn't persist tab/window switching (read description)

IMO Bug 103720 should have much higher priority

(Why is this bug blocking bug 207655, which is a dup.)?

    
    

    
  
Thanks to Tim, we now have a simple 1-line patch to fix bug 103720 that
leverages the fix for this bug. I hope we can get both patches landed. Also, at
least as far as Tim's patch for 103720 goes, the dependency tree should be
reversed. 103720 now depends on 104788, and 104788 should block 103720.

    
    

    
  
"103720 now depends on 104788, and 104788 should block 103720"

Mr. Sabol: I suspect you meant s/104788/104778/g right?  Making it so.

Mr. GAUTHERIE: Moving description parts that actually describe bug 103720
from this bug to 103720.
Blocks: 103720
No longer depends on: 103720
Summary: URI written in location bars doesn't persist tab/window switching (empty tab says "about:blank") (URL is lost when switching tabs if the page hasn't been loaded) (incomplete url is forgotten upon tab switching) → URI written in location bars doesn't persist tab/window switching (incomplete url is forgotten upon tab switching)
No longer blocks: 207655

    
    

    
  
Comment on attachment 125085 [details] [diff] [review]
Same as above but minus clean-up and for 1.4branch

>@@ -1300,6 +1300,8 @@
>         else
>           gURLBar.value = "";
> 
>+        gBrowser.userTypedValue = null;
>+

>@@ -1896,6 +1898,7 @@
>     } else { //if about:blank, urlbar becomes ""
>       gURLBar.value = "";
>     }
>+    gBrowser.userTypedValue = null;
Is it correct to reset userTypedValue for about:blank?

>@@ -318,19 +295,31 @@
>     // Update urlbar only if a new page was loaded on the primary content area
>     // Do not update urlbar if there was a subframe navigation
> 
>+    var browser = getBrowser().mCurrentBrowser;
>     if (aWebProgress.DOMWindow == content) {
>-      if (!this.userTyped.value) {
>+      var userTypedValue = browser.userTypedValue;
>+      if (userTypedValue !== null) {
>+        // Reset PageProxy ground state
>+        this.urlBar.value = location;
>+        // Setting the urlBar value in some cases causes userTypedValue
>+        // to become set, reset it to its old value
>+        browser.userTypedValue = userTypedValue;
>+        SetPageProxyState("valid", aLocation);
>+
>+        // And set it to user typed / invalid
>+        this.urlBar.value = userTypedValue;
>+        SetPageProxyState("invalid", null);
>+      } else {
>         this.urlBar.value = location;
>-        // the above causes userTyped.value to become true, reset it
>-        this.userTyped.value = false;
>+        // Setting the urlBar value in some cases causes userTypedValue
>+        // to become set, reset it to null
>+        browser.userTypedValue = null;
>+        SetPageProxyState("valid", aLocation);
>       }
I don't understand why you set the page proxy state to valid in both cases,
then reset it to invalid for the first case. Perhaps you have a test case for
which it is necessary?

>@@ -400,7 +408,7 @@
>                 if (securityUI)
>                   p.onSecurityChange(webProgress, null, securityUI.state);
>                 var listener = this.mTabListeners[this.mPanelContainer.selectedIndex];
>-                if (listener.mIcon)
>+                if (this.userTypedValue === null && listener.mIcon)
>                   p.onLinkIconAvailable(listener.mIcon);
Maybe this should go in nsBrowserStatusHandler.js because this isn't the only
call to onLinkIconAvailable().

    
    

    
  
> Is it correct to reset userTypedValue for about:blank?

Yeah. Say I have a blank tab and hit esc (restoring urlbar to ""). Now I switch
away and back to the tab. You'd expect "", not whatever you had typed before.
Oh, except I guess that since we assign "" to urlBar.value, userTypedValue would
become "". But then the proxy icon would look disabled, whereas for |null| it
would look enabled.

Same for resetting the value when opening new window / tab. Which reminds me, I
need to add some logic to the "open in new tab for accel+enter in urlbar" case
to reset the urlbar + userTypedValue.

> I don't understand why you set the page proxy state to valid in both cases,

When userTypedValue !== null I want to initialize the PageProxyState such that
its ground state (gLastValidURLStr) is the page's url so when you hit [Esc] the
right thing happens. I could replace the first SetPageProxyState with simply
gLastValidURLStr = location, but that's kinda ugly. The second call to it makes
the proxy icon reflect the fact that we're dealing with a user typed value in
the urlbar.

I could probably factor this out to make the code a bit clearer.

And yeah, I should move that check into onLinkIconAvailable, nice catch.

New patch coming up as soon as I figure out how to retain the user typed url
when you get e.g. "sadwewsda.com could not be found" for a tab in the background.

    
    

    
  
As you're doing a new patch can I just point out to change .mCurrentBrowser (the
field) to .selectedBrowser (the getter) for "neatness"? Thanks.

    
    

    
  
I was expecting the proxy icon to look disabled when the urlbar was empty. Good
catch on the open in new tab case, though. As for gLastValidURLStr, that's only
valid (pun intended) when the page proxy state is valid. Otherwise it's unused.

    
  

        Attachment #125085 -
        Flags: superreview?(sspitzer)

        Attachment #125085 -
        Flags: review?(neil.parkwaycc.co.uk)

    
  

        Attachment #125084 -
        Flags: superreview?(sspitzer)

        Attachment #125084 -
        Flags: review?(neil.parkwaycc.co.uk)

    
    

    
  


  

    
  

        Attachment #125084 -
        Attachment is obsolete: true

        Attachment #125085 -
        Attachment is obsolete: true

    
    

    
  
Except for the one about about:blank...
Steps:
1. Open blank tab
2. Type in location bar
3. Press ESC
4. Switch tabs
5. Switch back
Expected result: Disabled proxy icon
Actual result: Enabled proxy icon

    
    

    
  
Neil: yeah, but that's no different than with trunk builds.

    
    

    
  
Comment on attachment 125218 [details] [diff] [review]
Addresses Neil's comments

r=varga, tested on linux

        Attachment #125218 -
        Flags: review+

    
    

    
  


  

    
    

    
  
Comment on attachment 125258 [details] [diff] [review]
Same patch, branch style.

w00t!
um, I mean, a=asa (on behalf of drivers) for checkin to the 1.4 branch.

        Attachment #125258 -
        Flags: approval1.4+

    
    

    
  
a=adt  Please land this fix on the 1.4 branch and add the keyword fixed1.4

    
    

    
  
This isn't checked in yet?

    
    

    
  
looking at the trunk and 1.4 branch tboxen, this was fixed last night.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Keywords: fixed1.4
Resolution: --- → FIXED

    
    

    
  
I'm wondering if this fix also works in Firebird?

I am also wondering if this has been checked in to the current development
trunk? and not just the 1.4 branch?

    
    

    
  
this looks good on the 1.4 branch (using 2003.06.10.0x-1.4 comm builds). thanks,
jag!
Keywords: fixed1.4 → verified1.4

    
    

    
  
Mozilla Firebird doesn't get any of these tabbrowser changes automatically. They
shouldn't be too hard to port though.
Keywords: verified1.4 → fixed1.4
Keywords: relnote

    
    

    
  
shouldn't this bug be left unresolved until the changes make it to fb ?

    
    

    
  
Firebird is a different product, outside this bug's scope.  Please file a new
bug for it.

    
    

    
  


  
Say a user types a url from another tab, e.g. bugzila.mozilla.org, and hits
enter. He gets an error dialog, goes back to the other tab to check it,
switches back to his original tab, and hrm, the url is gone.

This patch fixes that (and hopefully doesn't break too much stuff in the
process ;-) ).

    
    

    
  


  

        Attachment #125475 -
        Attachment is obsolete: true

    
    

    
  
doh, pasted wrong bug.
real bug: bug 203102

sorry for spam

    
    

    
  


  
If the user types a faulty url, remember what he typed when switching tabs.

        Attachment #125491 -
        Attachment is obsolete: true

    
  

        Attachment #125492 -
        Flags: superreview?(bryner)

        Attachment #125492 -
        Flags: review?(riceman+bmo)

        Attachment #125492 -
        Flags: approval1.4?

    
    

    
  
Comment on attachment 125492 [details] [diff] [review]
Also remember what the user tried to load, v1.2

sr=bryner

        Attachment #125492 -
        Flags: superreview?(bryner) → superreview+

    
    

    
  
Comment on attachment 125492 [details] [diff] [review]
Also remember what the user tried to load, v1.2

a=asa (on behalf of drivers) for checkin to the 1.4 branch.

        Attachment #125492 -
        Flags: approval1.4? → approval1.4+

    
    

    
  
Comment on attachment 125492 [details] [diff] [review]
Also remember what the user tried to load, v1.2

     var browser = getBrowser().selectedBrowser;
     if (aWebProgress.DOMWindow == content) {
+      // The document loaded correctly, clear the value if we should
+      if (browser.userTypedClear)
+	 browser.userTypedValue = null;
+
       var userTypedValue = browser.userTypedValue;
       if (userTypedValue === null) {
	 this.urlBar.value = location;

It seems to me that there should be a way of simplyfing the resulting code
(which would unfortunately complicate the patch :-)

Possible nit: after opening a broken link in a new window, then opening a new
tab, the url is lost in the original tab :-(

        Attachment #125492 -
        Flags: review?(riceman+bmo) → review+

    
    

    
  
That nit was easy enough to fix, just like in addTab, add a
browser.userTypedValue = uriToLoad; right before the loadURI.

Last patch checked into trunk and branch.

    
    

    
  
tests in comment 0 and comment 181 work fine --tested with 2003.06.13.05-1.4 on
mac os x 10.2.6.

    
    

    
  
Sarah, can we mark this bug verified1.4?

    
    

    
  
i'm unable to verify on linux for the 1.4 commercial branch.

this is verified1.4 on mac os x and win2k (2003.06.16.05-1.4), though.
Whiteboard: [adt2][Hixie-P0][MB][ETA: 2003-06-06] → [adt2][Hixie-P0][MB][ETA: 2003-06-06][verified on mac/win branch]

    
    

    
  
I noticed one things, dont know though if this is the correct bug to mention
this (sorry for spam if wrong bug).
But:
If you do things like in comment 0, and the server is currently down, url stays,
that is good, but then the reload button doesnt work, only way to try again is
to press enter in the url field or press go.

    
    

    
  
vrfy'd fixed on linux rh8.0, 2003.06.17.11-1.4 comm branch build.
Keywords: fixed1.4 → verified1.4
Whiteboard: [adt2][Hixie-P0][MB][ETA: 2003-06-06][verified on mac/win branch] → [adt2][Hixie-P0][MB][ETA: 2003-06-06]

    
    

    
  
v
Status: RESOLVED → VERIFIED

    
    

    
  
Re comment 193:

Not this bug, since this bug is about remembering the typed text after tab
switching.

What you describe also happens without using tabs:
If the URL doesn't load; you get an error dialog, and the proxy icon stays grayed;
Then if you Reload, the previous URL (the one still displayed) in the history
(if there is one) reloads, and the typed text is replaced by that URL.

If you believe that this behaviour should be changed, look_for/file such a
(different) bug: a good start could be bug 28586 !

Thanks.


    
    

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

    
    

    
  
Sometimes I encountered with this problem: fire a URL in one tab,
switch to another tab and do some browsing, switch back to the
first tab, the page does not load, but the URL is left intact
(before fixing this bug the URL changed to something like about:blank).

Does that mean the bug is not fully fixed, or the problem is
addressed in another bug?

    
    

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

    
    

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

        Attachment #114446 -
        Flags: review?(shliang)

    
  
No longer blocks: majorbugs
Product: Core → SeaMonkey

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: