Last Comment Bug 104778 - URI written in location bars doesn't persist tab/window switching (incomplete url is forgotten upon tab switching)
: URI written in location bars doesn't persist tab/window switching (incomplete...
Status: VERIFIED FIXED
[adt2][Hixie-P0][MB][ETA: 2003-06-06]
: dataloss
Product: SeaMonkey
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: Trunk
: All All
: -- critical with 45 votes (vote)
: mozilla1.4beta
Assigned To: jag (Peter Annema)
: sairuh (rarely reading bugmail)
Mentors:
: 110128 111874 112284 116733 117100 125673 129320 130060 130444 135188 138805 139399 142298 142972 143537 144452 144721 146586 148116 148620 152253 155778 156842 159537 162661 165631 171092 173386 178181 178728 180712 182427 183322 183356 184763 185387 188601 189782 192498 197525 198608 198680 201462 205931 206935 210404 211337 (view as bug list)
Depends on:
Blocks: 103720 203102
  Show dependency treegraph
 
Reported: 2001-10-15 00:02 PDT by Adam Hauner
Modified: 2009-10-08 00:51 PDT (History)
124 users (show)
asa: blocking1.4a-
asa: blocking1.4b-
asa: blocking1.4+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
diff -u (1.44 KB, patch)
2002-05-05 10:25 PDT, HJ
Morten: review+
Details | Diff | Review
First try (1.73 KB, patch)
2002-10-02 05:40 PDT, neil@parkwaycc.co.uk
no flags Details | Diff | Review
Another go (3.31 KB, patch)
2003-02-14 09:15 PST, neil@parkwaycc.co.uk
jag-mozilla: superreview+
Details | Diff | Review
The not-nearly-as-scary-as-I-suspected patch (38.55 KB, patch)
2003-06-06 03:55 PDT, jag (Peter Annema)
no flags Details | Diff | Review
Same patch minus clean-up, for 1.4 branch (14.20 KB, patch)
2003-06-06 04:29 PDT, jag (Peter Annema)
no flags Details | Diff | Review
Fixes a few bugs with url and proxy not updating correctly (23.13 KB, patch)
2003-06-06 06:26 PDT, jag (Peter Annema)
no flags Details | Diff | Review
Same as above but minus clean-up and for 1.4branch (9.32 KB, patch)
2003-06-06 06:31 PDT, jag (Peter Annema)
no flags Details | Diff | Review
Addresses Neil's comments (23.39 KB, patch)
2003-06-09 03:57 PDT, jag (Peter Annema)
jvarga: review+
bugs: superreview+
Details | Diff | Review
Same patch, branch style. (10.28 KB, patch)
2003-06-09 15:31 PDT, jag (Peter Annema)
asa: approval1.4+
Details | Diff | Review
Also remember what the user tried to load (2.30 KB, patch)
2003-06-11 18:14 PDT, jag (Peter Annema)
no flags Details | Diff | Review
Also remember what the user tried to load (6.98 KB, patch)
2003-06-12 00:42 PDT, jag (Peter Annema)
no flags Details | Diff | Review
Also remember what the user tried to load, v1.2 (7.70 KB, patch)
2003-06-12 01:32 PDT, jag (Peter Annema)
neil: review+
bryner: superreview+
asa: approval1.4+
Details | Diff | Review

Description Adam Hauner 2001-10-15 00:02:56 PDT
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.
Comment 1 Waheed Islam 2001-10-15 01:47:42 PDT
i'm not sure, but i think this is more of an enhancement rather than a bug.
however, many other people may disagree.
Comment 2 Adam Hauner 2001-10-15 02:41:30 PDT
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.
Comment 3 Chase Tingley 2001-10-15 06:42:03 PDT
This sounds like a bug to me.

Confirmed linux 0.9.5 and my trunk build from a couple days ago.
Comment 4 Thorsten Konetzko 2001-10-27 02:03:22 PDT
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
Comment 5 R.K.Aa. 2001-11-27 17:48:40 PST
*** Bug 112284 has been marked as a duplicate of this bug. ***
Comment 6 Eugene Savitsky 2001-11-27 18:57:52 PST
It's a dataloss.
Comment 7 Eugene Savitsky 2001-11-28 03:02:19 PST
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. :(
Comment 8 sairuh (rarely reading bugmail) 2002-01-04 10:57:55 PST
*** Bug 117100 has been marked as a duplicate of this bug. ***
Comment 9 Brett Denny 2002-01-05 03:14:07 PST
*** Bug 116733 has been marked as a duplicate of this bug. ***
Comment 10 David Hyatt 2002-01-21 13:55:00 PST
Reassigning to new component owner.
Comment 11 R.K.Aa. 2002-02-15 14:51:35 PST
*** Bug 125673 has been marked as a duplicate of this bug. ***
Comment 12 Jeremy M. Dolan 2002-02-17 19:11:21 PST
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).
Comment 13 Peter Trudelle 2002-02-21 12:48:35 PST
nsbeta1- per ADT triage team
Comment 14 Jason Wies 2002-03-04 22:48:23 PST
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.
Comment 15 Jonas Jørgensen 2002-03-05 04:49:56 PST
*** Bug 110128 has been marked as a duplicate of this bug. ***
Comment 16 Markus Långström 2002-03-06 11:47:59 PST
*** Bug 129320 has been marked as a duplicate of this bug. ***
Comment 17 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-03-11 09:29:12 PST
*** Bug 130060 has been marked as a duplicate of this bug. ***
Comment 18 Peter Trudelle 2002-03-12 22:37:42 PST
*** Bug 130444 has been marked as a duplicate of this bug. ***
Comment 19 seb bacon 2002-03-19 04:06:16 PST
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.
Comment 20 Tuukka Tolvanen (sp3000) 2002-04-13 10:50:20 PDT
*** Bug 135188 has been marked as a duplicate of this bug. ***
Comment 21 Hixie (not reading bugmail) 2002-04-14 12:18:40 PDT
*** Bug 111874 has been marked as a duplicate of this bug. ***
Comment 22 Mike Kowalski 2002-04-18 20:53:52 PDT
*** Bug 138203 has been marked as a duplicate of this bug. ***
Comment 23 Felix Miata 2002-04-19 05:37:28 PDT
Can someone please change the summary to better reflect the undesirable behavior?
Comment 24 timeless 2002-04-19 06:00:34 PDT
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?
Comment 25 Mikel Ward 2002-04-19 17:37:01 PDT
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"
Comment 26 John Levon 2002-04-20 09:23:18 PDT
*** Bug 138805 has been marked as a duplicate of this bug. ***
Comment 27 Peter Trudelle 2002-04-20 21:43:07 PDT
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
Comment 28 John Levon 2002-04-26 19:38:22 PDT
*** Bug 139399 has been marked as a duplicate of this bug. ***
Comment 29 Damian Yerrick 2002-04-29 07:36:48 PDT
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 .
Comment 30 R.K.Aa. 2002-05-04 15:29:52 PDT
see bug 142298
Comment 31 HJ 2002-05-04 17:54:25 PDT
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!

Comment 32 HJ 2002-05-04 18:57:05 PDT
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.
Comment 33 HJ 2002-05-04 20:29:44 PDT
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?
Comment 34 HJ 2002-05-05 02:58:39 PDT
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.
Comment 35 HJ 2002-05-05 10:25:39 PDT
Created attachment 82403 [details] [diff] [review]
diff -u

This patch will fix issue #1 of this bug, have fun.
Comment 36 HJ 2002-05-05 10:56:57 PDT
*** Bug 142298 has been marked as a duplicate of this bug. ***
Comment 37 HJ 2002-05-05 10:59:11 PDT
The patch will also fix issue #2 (bug 142298) so that has been marked as a dup
of this bug.
Comment 38 Morten Nilsen 2002-05-05 11:05:33 PDT
Comment on attachment 82403 [details] [diff] [review]
diff -u

looks good, r=morten@nilsen.com
Comment 39 R.K.Aa. 2002-05-08 05:29:49 PDT
*** Bug 142972 has been marked as a duplicate of this bug. ***
Comment 40 Jesse Ruderman 2002-05-10 15:16:30 PDT
*** Bug 143537 has been marked as a duplicate of this bug. ***
Comment 41 Alfonso Martinez 2002-05-14 11:45:51 PDT
*** Bug 144452 has been marked as a duplicate of this bug. ***
Comment 42 Christopher Aillon (sabbatical, not receiving bugmail) 2002-05-15 04:04:01 PDT
*** Bug 144721 has been marked as a duplicate of this bug. ***
Comment 43 paxunix 2002-05-15 07:44:11 PDT
Will this fix also fix 111086?  That's currently (falsely) marked as WORKSFORME,
but may be related to this.
Comment 44 HJ 2002-05-15 11:21:03 PDT
No, not yet. However, I will try to solve this issue also. 

FYI: I reopened that other bug :)
Comment 45 mythor 2002-05-30 06:38:19 PDT
*** Bug 148116 has been marked as a duplicate of this bug. ***
Comment 46 R.K.Aa. 2002-06-02 08:00:13 PDT
*** Bug 148620 has been marked as a duplicate of this bug. ***
Comment 47 Michael Lefevre 2002-06-10 16:14:16 PDT
*** Bug 138805 has been marked as a duplicate of this bug. ***
Comment 48 Alfonso Martinez 2002-06-17 06:07:31 PDT
*** Bug 152253 has been marked as a duplicate of this bug. ***
Comment 49 Bruno Trevisan [Async Open Source] 2002-06-28 11:20:51 PDT
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.
Comment 50 Marc Boullet 2002-07-04 08:05:50 PDT
*** Bug 155778 has been marked as a duplicate of this bug. ***
Comment 51 Olav Vitters 2002-07-11 00:22:31 PDT
*** Bug 156842 has been marked as a duplicate of this bug. ***
Comment 52 Samir Gehani 2002-07-16 14:58:26 PDT
Nav triage team: nsbeta1+/adt2
Comment 53 jag (Peter Annema) 2002-07-17 17:43:12 PDT
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.
Comment 54 Damian Yerrick 2002-07-27 11:30:53 PDT
Issue 3 of comment 33 is exactly bug 103720.
Comment 55 Olav Vitters 2002-08-14 04:51:26 PDT
*** Bug 162661 has been marked as a duplicate of this bug. ***
Comment 56 Stefan Winterstein 2002-08-21 04:49:01 PDT
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.
Comment 57 Daniel Wang 2002-08-29 22:08:01 PDT
*** Bug 165631 has been marked as a duplicate of this bug. ***
Comment 58 llanero 2002-09-07 04:45:29 PDT
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.
Comment 59 Andrew Schultz 2002-09-26 20:11:36 PDT
*** Bug 171092 has been marked as a duplicate of this bug. ***
Comment 60 Garth Wallace 2002-10-02 00:35:15 PDT
*** Bug 146586 has been marked as a duplicate of this bug. ***
Comment 61 neil@parkwaycc.co.uk 2002-10-02 05:40:42 PDT
Created attachment 101396 [details] [diff] [review]
First try
Comment 62 Andrew Schultz 2002-10-08 18:13:03 PDT
*** Bug 173386 has been marked as a duplicate of this bug. ***
Comment 63 Alex Bishop 2002-11-02 14:40:48 PST
Are we sure the summary's long enough now?
Comment 64 R.K.Aa. 2002-11-03 12:06:49 PST
*** Bug 178181 has been marked as a duplicate of this bug. ***
Comment 65 Torben 2002-11-05 05:35:57 PST
Bug 159537 is very simmilar, but does not involve tabs.
Comment 66 Torben 2002-11-05 07:12:22 PST
*** Bug 159537 has been marked as a duplicate of this bug. ***
Comment 67 Torben 2002-11-05 07:15:19 PST
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)
Comment 68 Pratik 2002-11-06 14:27:24 PST
*** Bug 178728 has been marked as a duplicate of this bug. ***
Comment 69 Olivier Cahagne 2002-11-18 08:21:01 PST
*** Bug 180712 has been marked as a duplicate of this bug. ***
Comment 70 Torben 2002-11-28 05:00:58 PST
*** Bug 182427 has been marked as a duplicate of this bug. ***
Comment 71 R.K.Aa. 2002-12-03 16:36:36 PST
*** Bug 183322 has been marked as a duplicate of this bug. ***
Comment 72 Greg K. 2002-12-04 10:42:52 PST
*** Bug 183356 has been marked as a duplicate of this bug. ***
Comment 73 Jay Davis 2002-12-09 16:59:51 PST
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.
Comment 74 Jay Davis 2002-12-09 17:13:59 PST
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!
Comment 75 Mark Thomas 2002-12-10 06:00:15 PST
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.
Comment 76 resigned 2002-12-10 06:05:22 PST
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.
Comment 77 resigned 2002-12-10 06:10:20 PST
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.
Comment 78 Sébastien Delahaye 2002-12-11 12:03:07 PST
*** Bug 184763 has been marked as a duplicate of this bug. ***
Comment 79 Matthias Versen [:Matti] 2002-12-14 11:42:31 PST
*** Bug 185387 has been marked as a duplicate of this bug. ***
Comment 80 Joe M 2002-12-22 15:51:51 PST
does the work on bug 28586 help with this?
Comment 81 Andrew Hagen 2002-12-22 17:30:37 PST
No. If you enable error pages, you still get the same problem.
Comment 82 Matthias Versen [:Matti] 2003-01-10 16:46:46 PST
*** Bug 188601 has been marked as a duplicate of this bug. ***
Comment 83 Alex Maneu 2003-01-16 15:45:03 PST
Adding myself to CC.
Comment 84 Brant Gurganus 2003-01-18 18:11:36 PST
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 85 jag (Peter Annema) 2003-01-20 00:58:03 PST
Shuehan has graciously agreed to take this bug from me.
Comment 86 jag (Peter Annema) 2003-01-20 00:59:18 PST
Right.
Comment 87 jag (Peter Annema) 2003-01-24 09:58:47 PST
And taking it back.
Comment 88 andreas 2003-02-08 05:40:13 PST
#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...
Comment 89 Alfonso Martinez 2003-02-09 15:28:12 PST
*** Bug 192498 has been marked as a duplicate of this bug. ***
Comment 90 neil@parkwaycc.co.uk 2003-02-13 13:13:25 PST
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.
Comment 91 Andrew Hagen 2003-02-13 14:50:23 PST
See also the patch posted to this in bug 103720.
Comment 92 neil@parkwaycc.co.uk 2003-02-14 04:08:58 PST
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).
Comment 93 neil@parkwaycc.co.uk 2003-02-14 09:15:40 PST
Created attachment 114446 [details] [diff] [review]
Another go

This is still only to address the issue of losing the url as you are typing it.
Comment 94 Ed Sabol 2003-02-14 10:59:55 PST
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?
Comment 95 R.K.Aa. 2003-03-15 03:54:30 PST
*** Bug 197525 has been marked as a duplicate of this bug. ***
Comment 96 Daniel Wang 2003-03-18 11:40:28 PST
*** Bug 189782 has been marked as a duplicate of this bug. ***
Comment 97 jag (Peter Annema) 2003-03-21 04:35:20 PST
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.
Comment 98 Torben 2003-03-21 13:19:51 PST
*** Bug 198608 has been marked as a duplicate of this bug. ***
Comment 99 Sébastien Delahaye 2003-03-21 23:35:46 PST
*** Bug 198680 has been marked as a duplicate of this bug. ***
Comment 100 Matthias Versen [:Matti] 2003-03-31 13:14:40 PST
*** Bug 199997 has been marked as a duplicate of this bug. ***
Comment 101 writser 2003-04-02 16:11:50 PST
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
Comment 102 Mike Fedyk 2003-04-02 16:20:59 PST
Except that IE...

DOESN'T HAVE TABS!
Comment 103 Eugene Savitsky 2003-04-06 16:01:35 PDT
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.
Comment 104 NetVicious 2003-04-06 23:34:10 PDT
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.
Comment 105 timeless 2003-04-07 01:11:41 PDT
thank you for volunteering, please fix it asap.
Comment 106 NetVicious 2003-04-07 01:57:50 PDT
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.
Comment 107 David G King 2003-04-07 04:08:57 PDT
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.
Comment 108 Craig 2003-04-07 04:39:20 PDT
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.
Comment 109 Jonadab the Unsightly One (Nathan Eady) 2003-04-07 06:44:40 PDT
<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>
Comment 110 Sébastien Delahaye 2003-04-10 03:54:32 PDT
*** Bug 201468 has been marked as a duplicate of this bug. ***
Comment 111 Torben 2003-04-10 05:27:41 PDT
*** Bug 201462 has been marked as a duplicate of this bug. ***
Comment 112 Sébastien Delahaye 2003-04-10 05:59:54 PDT
*** Bug 201462 has been marked as a duplicate of this bug. ***
Comment 113 Daniel Kabs, reporting bugs since 2002 2003-04-10 09:06:57 PDT
Hi,

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

Cheers
Daniel Kabs

Germany
Comment 114 WD 2003-04-10 09:25:50 PDT
*** Bug 201468 has been marked as a duplicate of this bug. ***
Comment 115 tyl2 2003-05-11 14:32:46 PDT
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.
Comment 116 Bill Mason 2003-05-16 08:36:14 PDT
*** Bug 205931 has been marked as a duplicate of this bug. ***
Comment 117 Serge Gautherie (:sgautherie) 2003-05-20 16:31:05 PDT
[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.)
Comment 118 Tom Sommer 2003-05-20 16:54:19 PDT
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
Comment 119 Serge Gautherie (:sgautherie) 2003-05-20 17:13:56 PDT
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) !
Comment 120 Manko 2003-05-21 00:50:14 PDT
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.
Comment 121 Serge Gautherie (:sgautherie) 2003-05-21 02:08:57 PDT
[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.
Comment 122 Michel Meyers 2003-05-21 02:15:00 PDT
"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.
Comment 123 Manko 2003-05-21 02:18:39 PDT
Oh, sorry, sorry.....
Comment 124 Hermann Schwab 2003-05-22 15:59:06 PDT
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?
Comment 125 Serge Gautherie (:sgautherie) 2003-05-22 16:19:53 PDT
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 126 jag (Peter Annema) 2003-05-22 17:12:38 PDT
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.
Comment 127 Karl Palsson 2003-05-22 17:29:54 PDT
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.
Comment 128 Andrew Hagen 2003-05-22 18:04:45 PDT
"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.
Comment 129 Hixie (not reading bugmail) 2003-05-22 18:21:07 PDT
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.
Comment 130 Jason Bassford 2003-05-22 19:12:31 PDT
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.
Comment 131 Alonso Acuña 2003-05-23 00:05:07 PDT
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.
Comment 132 neil@parkwaycc.co.uk 2003-05-23 05:57:44 PDT
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)?
Comment 133 Hixie (not reading bugmail) 2003-05-23 06:09:40 PDT
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
Comment 134 resigned 2003-05-23 14:48:51 PDT
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.
Comment 135 NetVicious 2003-05-23 14:57:11 PDT
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
Comment 136 Tom Sommer 2003-05-23 15:02:54 PDT
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?)
Comment 137 Santos 2003-05-23 15:48:48 PDT
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. 
Comment 138 Santos 2003-05-23 15:51:07 PDT
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. 
Comment 139 resigned 2003-05-23 16:13:38 PDT
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.). 
Comment 140 Matthias Versen [:Matti] 2003-05-23 18:16:23 PDT
*** Bug 206935 has been marked as a duplicate of this bug. ***
Comment 141 llanero 2003-05-24 14:26:42 PDT
Following the status of the bug is not worth the spam. Not for a simple bug.
Comment 142 noririty 2003-05-29 01:02:59 PDT
*** Bug 207458 has been marked as a duplicate of this bug. ***
Comment 143 [:jesup] on pto until 2016/7/5 Randell Jesup 2003-05-29 09:05:30 PDT
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.
Comment 144 [:jesup] on pto until 2016/7/5 Randell Jesup 2003-06-02 15:27:38 PDT
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.
Comment 145 Ed Sabol 2003-06-02 21:09:24 PDT
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.
Comment 146 Tom Schneider 2003-06-02 21:39:10 PDT
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.
Comment 147 David G King 2003-06-02 21:51:21 PDT
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.
Comment 148 jag (Peter Annema) 2003-06-06 03:55:03 PDT
Created attachment 125080 [details] [diff] [review]
The not-nearly-as-scary-as-I-suspected patch
Comment 149 jag (Peter Annema) 2003-06-06 04:29:24 PDT
Created attachment 125081 [details] [diff] [review]
Same patch minus clean-up, for 1.4 branch
Comment 150 jag (Peter Annema) 2003-06-06 06:26:08 PDT
Created attachment 125084 [details] [diff] [review]
Fixes a few bugs with url and proxy not updating correctly
Comment 151 jag (Peter Annema) 2003-06-06 06:31:39 PDT
Created attachment 125085 [details] [diff] [review]
Same as above but minus clean-up and for 1.4branch
Comment 152 Adam D. Moss 2003-06-06 07:06:02 PDT
Great, that certainly seems to work (moz1.4-cvs, Linux/x86).
Comment 153 Adam D. Moss 2003-06-06 07:24:04 PDT
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.)
Comment 154 Tim 2003-06-06 08:57:33 PDT
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.
Comment 155 Adam D. Moss 2003-06-06 09:07:41 PDT
Nah, that didn't help.
Comment 156 Serge Gautherie (:sgautherie) 2003-06-06 13:46:21 PDT
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 ?
Comment 157 Adam D. Moss 2003-06-06 13:50:48 PDT
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...
Comment 158 Serge Gautherie (:sgautherie) 2003-06-06 14:11:06 PDT
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 !?
Comment 159 Tom Sommer 2003-06-06 15:13:14 PDT
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.)?
Comment 160 Ed Sabol 2003-06-06 21:52:02 PDT
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.
Comment 161 Damian Yerrick 2003-06-06 22:25:17 PDT
"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.
Comment 162 neil@parkwaycc.co.uk 2003-06-07 09:36:02 PDT
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().
Comment 163 jag (Peter Annema) 2003-06-07 10:10:00 PDT
> 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.
Comment 164 neil@parkwaycc.co.uk 2003-06-08 09:46:56 PDT
As you're doing a new patch can I just point out to change .mCurrentBrowser (the
field) to .selectedBrowser (the getter) for "neatness"? Thanks.
Comment 165 neil@parkwaycc.co.uk 2003-06-08 13:29:21 PDT
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.
Comment 166 jag (Peter Annema) 2003-06-09 03:57:01 PDT
Created attachment 125218 [details] [diff] [review]
Addresses Neil's comments
Comment 167 neil@parkwaycc.co.uk 2003-06-09 06:24:25 PDT
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
Comment 168 jag (Peter Annema) 2003-06-09 10:39:13 PDT
Neil: yeah, but that's no different than with trunk builds.
Comment 169 Ben Goodger (use ben at mozilla dot org for email) 2003-06-09 10:50:00 PDT
Comment on attachment 125218 [details] [diff] [review]
Addresses Neil's comments

sr=ben@netscape.com
Comment 170 Jan Varga [:janv] 2003-06-09 11:09:39 PDT
Comment on attachment 125218 [details] [diff] [review]
Addresses Neil's comments

r=varga, tested on linux
Comment 171 jag (Peter Annema) 2003-06-09 15:31:22 PDT
Created attachment 125258 [details] [diff] [review]
Same patch, branch style.
Comment 172 Asa Dotzler [:asa] 2003-06-09 15:58:41 PDT
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.
Comment 173 Paul Wyskoczka 2003-06-10 06:41:01 PDT
a=adt  Please land this fix on the 1.4 branch and add the keyword fixed1.4
Comment 174 Christopher Blizzard (:blizzard) 2003-06-10 09:09:39 PDT
This isn't checked in yet?
Comment 175 sairuh (rarely reading bugmail) 2003-06-10 10:11:08 PDT
looking at the trunk and 1.4 branch tboxen, this was fixed last night.
Comment 176 Tom Sommer 2003-06-10 10:32:21 PDT
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?
Comment 177 sairuh (rarely reading bugmail) 2003-06-10 11:33:08 PDT
this looks good on the 1.4 branch (using 2003.06.10.0x-1.4 comm builds). thanks,
jag!
Comment 178 jag (Peter Annema) 2003-06-10 13:44:57 PDT
Mozilla Firebird doesn't get any of these tabbrowser changes automatically. They
shouldn't be too hard to port though.
Comment 179 Az 2003-06-11 04:25:59 PDT
shouldn't this bug be left unresolved until the changes make it to fb ?
Comment 180 Jason Bassford 2003-06-11 06:00:44 PDT
Firebird is a different product, outside this bug's scope.  Please file a new
bug for it.
Comment 181 jag (Peter Annema) 2003-06-11 18:14:01 PDT
Created attachment 125475 [details] [diff] [review]
Also remember what the user tried to load

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 ;-) ).
Comment 182 Niklas (dacovale) Bolmdahl 2003-06-12 00:37:01 PDT
re comment #179
see bug #207655
Comment 183 jag (Peter Annema) 2003-06-12 00:42:17 PDT
Created attachment 125491 [details] [diff] [review]
Also remember what the user tried to load
Comment 184 Niklas (dacovale) Bolmdahl 2003-06-12 00:48:20 PDT
doh, pasted wrong bug.
real bug: bug 203102

sorry for spam
Comment 185 jag (Peter Annema) 2003-06-12 01:32:46 PDT
Created attachment 125492 [details] [diff] [review]
Also remember what the user tried to load, v1.2

If the user types a faulty url, remember what he typed when switching tabs.
Comment 186 Brian Ryner (not reading) 2003-06-12 01:59:23 PDT
Comment on attachment 125492 [details] [diff] [review]
Also remember what the user tried to load, v1.2

sr=bryner
Comment 187 Asa Dotzler [:asa] 2003-06-12 02:04:13 PDT
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.
Comment 188 neil@parkwaycc.co.uk 2003-06-12 05:54:14 PDT
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 :-(
Comment 189 jag (Peter Annema) 2003-06-12 06:16:51 PDT
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.
Comment 190 sairuh (rarely reading bugmail) 2003-06-13 13:07:30 PDT
tests in comment 0 and comment 181 work fine --tested with 2003.06.13.05-1.4 on
mac os x 10.2.6.
Comment 191 Paul Wyskoczka 2003-06-16 08:32:08 PDT
Sarah, can we mark this bug verified1.4?
Comment 192 sairuh (rarely reading bugmail) 2003-06-16 12:00:48 PDT
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.
Comment 193 José Jeria 2003-06-18 02:13:46 PDT
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.
Comment 194 sairuh (rarely reading bugmail) 2003-06-18 12:07:03 PDT
vrfy'd fixed on linux rh8.0, 2003.06.17.11-1.4 comm branch build.
Comment 195 Vedran Miletic 2003-06-18 14:46:56 PDT
v
Comment 196 Serge Gautherie (:sgautherie) 2003-06-18 15:37:41 PDT
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.
Comment 197 Michiel van Leeuwen (email: mvl+moz@) 2003-06-23 13:20:19 PDT
*** Bug 210404 has been marked as a duplicate of this bug. ***
Comment 198 Wenqing Jiang 2003-06-27 12:04:46 PDT
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?
Comment 199 Simon Paquet [:sipaq] 2003-07-02 02:23:43 PDT
*** Bug 211337 has been marked as a duplicate of this bug. ***
Comment 200 Simon Paquet [:sipaq] 2003-08-12 08:57:08 PDT
*** Bug 215939 has been marked as a duplicate of this bug. ***

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