Closed Bug 405239 Opened 17 years ago Closed 16 years ago

Cookie confirmation dialog focuses a newly opened "background" tab

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: breght, Assigned: jst)

References

Details

(Keywords: fixed1.9.1, regression, verified1.9.0.5)

Attachments

(5 files)

Dialog bar proposal
98.39 KB, image/png
Details
modal dialogs on one tab shown for different tabs
84.50 KB, image/png
Details
Fix.
964 bytes, patch
sicking
: review+
sicking
: superreview+
Details | Diff | Splinter Review
With comment.
1.19 KB, patch
jst
: review+
jst
: superreview+
sicking
: approval1.9.1+
dveditz
: approval1.9.0.5+
Details | Diff | Splinter Review
For checkin.
1.50 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1

I have the option "ask me every time" option set for cookies. If a new tab is opened by middle-clicking a link and the page in the newly opened tab wishes to set a cookie, this new page is automatically focused. 

Suggestion: make the cookie confirmation window non-modal and replace it by a mechanism similar to the "remember password"-bar (or "allow content to install"-bar) at the top of the screen. In this way, each tab can have its own non-intrusive cookie confirmation. Furthermore, it creates a more uniform way of requesting user interaction. 

Reproducible: Always

Steps to Reproduce:
1. Set option "ask me every time"  (and check "allow cookies" option) in Tools -> Options -> Privacy -> Cookies. Furthermore, make sure that Tools -> Options -> Tabs -> "When I open a link in a new tab, switch to it immediately" is UNchecked,
2. Navigate to a page that contains links (e.g. a google search page),
3. Middle-click a link (hopefully one that will set a cookie)
Actual Results:  
The newly opened tab is focused and a modal dialog opens requesting if a cookie may be set.

Expected Results:  
A new tab opens at the end of the list. If the tab is focused by the user, a confirmation dialog is displayed

As said in the introduction, I propose to replace the cookie confirmation _modal dialog_ by a info bar at the top of the window, similar to those that are displayed in case of pop-up blocking, software installation, "remember password" (in Firefox 3).
Seeing this in Seamonkey 2008010202 on Linux as well.  Not sure when it started happening, but cookie dialogue boxes used to just pop up without changing tab focus.

Similar behaviour in Camino is discussed in bug #302596.
Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Possibly bug 391777? Jonas, Jonny, take a peek?
Isn't this how we want it to work? I agree that it sucks that this dialog is modal. But while it is, it seems bad to open a dialog for a tab while keeping the tab in the background. That would be very confusing for the user I'd think.
The previous behavior *could* be confusing, I'll admit.  However, I frequently open several tabs at once, to websites that differ vastly in speed.  So it's not uncommon for me to be typing away in a text box on one tab, when a page loading in another tab gets to the point where it wants to set a cookie.  Because of how it works now, it's not possible for me to finish what I was writing, then deal with the dialog; instead, I've got to deal with the dialog, then switch back to the original tab, and only *then* can I finish what I was writing.  I have to break my chain of thought to deal with something that's not important to what I'm doing *right* *now*, and that's highly annoying.

Personally, I like the idea proposed by this bug's submitter.  If the dialog has to be modal, then don't make me deal with it on Firefox's time; let me deal with it on my own.
Summary: Cookie confirmation window focuses a newly opened "background" tab → Cookie confirmation dialog focuses a newly opened "background" tab
I agree that non-modal would be ideal, but that should be filed as a separate bug (though I'd think one already exists).

This bug I think is WONTFIX. Likely this started happening since FF2 since we fixed some bug in how we deal with modal dialog since in general we want modal dialogs to show the tab they refer to.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: blocking-firefox3? → blocking-firefox3-
Resolution: --- → WONTFIX
Making this feature "non-modal" really means improving the "un-downgrade" UI to the point where we can remove the ask-every-time feature.  And I think that is exactly what we should do.
agreed; the real fix here (and for all the other cookie dialog bugs) is to not have cookie dialogs. ;)
That seems to be covered in part by bug 310492 or bug 217199.
I'm just coming here from 422175 which was marked as duplicate.

Making this bug 'won't fix' without a solution in place is, at least for me and those who want to check which cookies get into their browser, a stopper for using firefox 3.

In firefox 2 I haven't seen a bug saying 'I want the cookies popup to bring the tab in foreground'. Therefore my proposition is until there is a solution to reverse the behaviour of the cookies popup as it was in Firefox 2. Simple as this! 


Seeing there is still no resolution, I think it is best to change status back to open.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
the reason these dialogs are modal is because they're blocking.

imagine this:
1. you have only 1 window with 1 tab.
2. you visit 1 web page which contains a dozen links to a second web server

assume you have never been to this other server before  and have your prefs set such that you will get cookie confirmation requests, and that each linked page will try to set a session cookie.

3. you right click each link and choose open in new background tab

we have a limit on the number of concurrent connections to a server (it's much less than 12).

4. when the first page opens in a background tab, it gets a response from the server which needs an answer from you, "store cookie, or don't". we actually need this answer *ASAP* because it affects what happens when you visit the other 11 links.
5. assume we change the behavior such that instead of a modal dialog, you get a non modal dialog which gets burried.
6. you proceed through the other links
7. you  now have not more than 6 tabs trying to load content and 6 tabs which aren't even allowed to make connections because of the connection limit (see 3).
8. you decide to randomly confirm or reject dialogs for the first 5 tabs.

sadly, nothing happens.

the ui thread in order to accomodate you looks like this:

_main_loop_
_network_response_ 1
_cookie_dialog_ 1 yes/no?
_nested_loop_ 1
_network_response_ 2
_cookie_dialog_ 2 yes/no?
_nested_loop_ 2
_network_response_ 3
_cookie_dialog_ 3 yes/no?
_nested_loop_ 3
_network_response_ 4
_cookie_dialog_ 4 yes/no?
_nested_loop_ 4
_network_response_ 5
_cookie_dialog_ 5 yes/no?
_nested_loop_ 5
_network_response_ 6
_cookie_dialog_ 6 yes/no?
_nested_loop_ 6

if you dismiss the dialogs for 1..5, you have the same stack:
_main_loop_
_network_response_ 1
_cookie_dialog_ 1 yes
_nested_loop_ 1
_network_response_ 2
_cookie_dialog_ 2 no
_nested_loop_ 2
_network_response_ 3
_cookie_dialog_ 3 yes
_nested_loop_ 3
_network_response_ 4
_cookie_dialog_ 4 no
_nested_loop_ 4
_network_response_ 5
_cookie_dialog_ 5 yes
_nested_loop_ 5
_network_response_ 6
_cookie_dialog_ 6 yes/no?
_nested_loop_ 6

until you dismiss the 6th dialog, *none* of your other responses will be handled.
worse still. assuming you give contradictory answers, there's no guarantee which answer will be used for any of them.

for more fun, it's almost certain that the server was trying to set a session cookie, and it has now offered you 6 unique session cookies.

at this point, you have 13 tabs, 5 dismissed dialogs, 1 critical path dialog, 6 tabs waiting in the stack, and 6 tabs that haven't even started to make any network requests at all. (this assumes 6 connections per server, the actual limit can easily be lower.)

this bug was wontfixed by a mozilla engineer. there are major architectural problems that would have to be solved in order to address this bug.

Worse, there are serious user experience problems that would need to be solved. e.g., what do you actually expect to have happen here?
fwiw, my personal view is that if we end up w/ multiple requests to set the same cookie, we should update the status and have only a single prompt that is shared amongst all the requests, so that when you make a decission, the other requests are dismissed. 

However, this doesn't solve the second problem:
Suppose you have 6 offered session cookies and you accept 1 of those dialogs, which session cookie do you want? you have 3 obvious choices (first cookie, last cookie, cookie from associated window/tab), you're also free to request "surprise me". Offhand, I think last-cookie makes a bit more sense than the others, but only a bit.

for people curious about my vastly oversimplified call stack, here's the slightly elongated version (still quite incomplete, OpenWindow probably costs another 6 or so stack frames, and OnStartRequest has to come form somewhere):
nsIWindowWatcher::OpenWindow
nsCookiePromptService::CookieDialog
nsCookiePermission::CanSetCookie
nsCookieService::SetCookieInternal
nsCookieService::SetCookieStringInternal
nsCookieService::SetCookieStringFromHttp
nsHttpChannel::SetCookie
nsHttpChannel::ProcessResponse
nsHttpChannel::OnStartRequest

Now, we could change nsHttpChannel::SetCookie to suspend the request and provide nsCookieService with a callback which it can use to unsuspend the request when it gets an answer. This would enable us to get rid of the nsHttpChannel section of the stack trace. CookieService would need to be rewritten to pass this callback down to the nsCookiePermission and nsCookiePromptService. The nsCookiePromptService would basically need to pass the callback to a UI which would use it when it's dismissed.

If you don't think this is a lot of work, then volunteer to sponsor an engineer at 50 USD/hr to fix it. Conservatively, I'd expect you to lose > $5000 on the deal. But I think you'd make some engineer busy for a couple of weeks. Note: even if an engineer does manage to do all this, there are still reviews, approvals, and processes to worry about. this is a *major* change in architecture and even though my own derivative needs this feature, I'd argue against it for 3.0.

Now, please, don't reopen this bug unless you're putting serious money where your mouse is.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → WONTFIX
OK it is pretty clear why the window needs to be modal, but don't you also understand why the window should appear to the currently viewing tab and not to change the tab to the cookie originating tab?

In very simple words: Bring back Firefox 2 behaviour. 
I agree that the previous behaviour seems preferable, for the reasons laid out in comment #8.  Mozilla's architecture may well be an obstacle to perfection in the case of modal dialogs, but that's no reason to make them even more intrusive.  

Foregrounding background tabs automatically is a regression, and maybe it's the fix that Jonas Sicking mentions in comment #9 that we should be tracking down and revisting.  A viable compromise might be to highlight the tab that's the source of the dialog.

Consider the common case of an ad server wanting to set a tracking cookie.  If I have two tabs loading in the background while I'm reading a third, do I really need to switch away from what I'm reading for a look at a mostly-unloaded page before I know how I want to answer a question about "content21.mega-ad-blitz.com" and its desire to set 27 cookies?
i'm sorry. what behavior are you guys talking about? out of the box, neither ff2 nor ff3 prompt you to accept cookies. this is the only common case. for the common case, nothing has changed, and nothing is broken.

you guys are all spending excess energy on cases which only cause headaches. ff3 has a keep [cookies] until I exit [ff3].

if you'd like, i can easily make the patch described in comment 10 (namely removing the feature). dwitte would be happy w/ that. it is not a regression from ff2 because as i state above, the default behavior doesn't do any of this. and it would mean that you will not have dialogs popping up background tabs.

that patch is easy. if you continue to comment in this bug, i promise to try to get that patch posted and committed for ff3. if you feel some absolute need for the dialog, I'd suggest you leave this bug alone, because the alternative is no dialog at all and everyone else will be much happier.
The bottom line, if you don't understand what we are talking about, is :

Make the cookie dialog appear on the current tab REGARDLESS of the tab that the cookie originated from!

This is the behaviour in FF2.

Thanks

Timeliess: we don't land punitive patches when we disagree with bug commenters.

That said, this bug is marked WONTFIX intentionally. Firefox always shows the associated tab whenever we open a modal dialog for that tab. Without doing that it becomes very hard to see which tab a dialog is associated with.

I guess an argument can be made that the cookie dialog opens often enough that switching tabs gets annoying. Maybe even to the point where we want to make an exception to the above rule. However I would urge you to raise this discussion with the UI folks in the newsgroups to see what makes most sense.

There are many extensions out there that improves the cookie dialog. I would suggest you use those until we have improved ours. It should even be possible to make an extension that does not switch tabs by parenting the modal dialog to the toplevel window rather than to the tab.
I do understand what you are requesting. However don't assume that everybody wants the same thing as you. We make improvements with each new release, sometimes not everyone agree with these improvements.

As I said, if you want this changed, please raise a discussion in the newsgroups.
Jonas: since you don't point to which comment you refer to, I assume that you refer to mine (since mine was the last one).

First of all: "...if you don't understand what we are talking about..." was pointed to timeless who doesn't seem to understand the issue.

What know I don't understand is why this behaviour changed from ff2 to ff3. Was it because of a filled bug or because the developers made (another) choice for the 'good of the user' without considering the user? This whole discussion points to the later, even your words "We make improvements with each new release,
sometimes not everyone agree with these improvements." mark this. 

Is this improvement? This bug points that it is not. Therefore as arbitrarily as you (the developers) make 'improvements' and ask the users beside a bug to also start a discussion in the newsgroups (for which you don't even consider that users have access or are willing to install a newsgroup client and start again repeating themselves over and over) so do we (the users) ask this 'improvement' to be reverted to the previous 'not improved' and 'confusing' state. 

Please note that I'm talking about the intermediate state of this feature since as it seems how it should be implemented is still under discussion. I also agree with timeless that this feature *must* annoy the user because the user asked for it, the users asked to be 'disturbed' about cookies. But it is different to inform the user about cookies and annoy him by changing focus between tabs. 

I propose that as intermediate solution you bring back the old behaviour and maybe is it simple enough to enhance it by adding the URL of the site whose tab initiated the cookie.
Camino's current behavior (automatically switch back to the tab you were using after you answer the cookie dialog) seems sane.  See bug 302596.
Note that there is nothing magical about a bug being filed, including this one. It just means that someone has an opinion about that something should work differently than it currently does.

I don't know if this was an intentional change or not. My guess is that this behavior changed since we fixed a generic bug regarding tab switching for modal dialogs.

If you want to make an exception to the general rule of how we handle modal dialogs this needs to be discussed in a wider audience. It would be wrong for just you and me to make this without giving more people a chance to chime in. This is why I suggested taking it to the news groups. Note that the newsgroups are available as mailing lists so all you need is a mail reader. Or you can use google groups. Neither require any software installation.

That said, Jesses suggested behavior, to switch back to the previous tab once the cookie dialog closes, sounds like a good suggestion. And should probably be done for all modal dialogs. I suggest that a new bug is filed (having a new bug rather than morphing this one will make it easier to follow what the new bug is actually for people that read just the first few comments)

1) it's not only cookies dialog boxes - also asking about changing encrypted to non-encrypted (and so on) pages (and this feature is out of box)
2) on - make this dialogs modal - but AFTER answering question (about cookies, or confirm partially encrypted page) RETURN to last active page (I'm on page1, open in background page2, page2 opens and want to store cookies - so modal window is shown [and page2 is becoming active], after accepting/rejecting cookies active page is set page1 [because this was active tab BEFORE modal window action])
One thing that still confuses me is why there are still two types of feedback mechanisms: 

  - (modal, focus-stealing) dialog boxes
  - the 'attention bar' at the top of the page (e.g. used for remember password question)

Is there a compelling reason to do this? From a usability point of view, I would say this is less than optimal. Isn't it an option to use _one_ mechanism for all user-feedback on a tab? (see attachment)

I very well understand that this requires rework in the 'critical path'. However, the present behavior is highly annoying and from a usability perspective unacceptable.
Attached image Dialog bar proposal — 
Proposal to unify all modal dialogs into a per-tab 'dialog bar'.
Oh, furthermore, I still believe that 'RESOLVED WONTFIX' is not the correct status for this bug.. 
there are 2 proposed solutions:
- everything in "dialog bar" (the same as ad plugin)
- restoring active tab after closing modal window

RESOLVED WONTFIX - should be removed and changed to open
I agree: restoring the active tab after closing the modal window may be a feasible solution for the short(er) term. In the mid-term, I believe that the foundation needs to have a discussion on how to approach user feedback mechanisms.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I agree, refocusing the tab the user was viewing when a modal dialog was opened by a background tab seems like something worthwhile considering, but please open a new bug on that, and a new bug on using a modal dialog bar or what not. This bug as filed remains WONTFIX.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → WONTFIX
(In reply to comment #33)
> I agree, refocusing the tab the user was viewing when a modal dialog was opened
> by a background tab seems like something worthwhile considering

That's already filed as bug 429287.
Maybe a way to appease more people at once would be a preference to toggle between the FF2 and FF3 behavior, with the current (FF3) behavior as the default?  (I would be happy even if such only appeared in about:config.)
^^^ One more user who will be installing an add-on that downgrades FF to his preferred UI behaviour.
You can bump the count of users unhappy with this change.  It makes the option to not switch to new tabs useless when they ask about cookies.  And as others have said it breaks user productivity as well.

I need to test what happens if I move to a different window manager page as well, given I spent half of today reconfiguring FVWM2 to stop windows being warped to, or stealing focus, when they use the 'URGENT' hint.  I suspect I'll end up with the cookies dialogue on the new page, as happened with FF2 on my setup.  Bang, there goes the "but we want to make sure you see the tab it's for!" argument.  I won't even be seeing the FF window when that happens.

So, anyone got an addon that 'fixes' this ?

Oh, and the bugzilla search is ****.  440060 was mine.  I DID search on "any of the words" "cookie focus tab" and didn't find this bug.

If I had to choose I'd prefer a config option to have the old FF2 behaviour (only in about:config if needs be, I was checking there today), but I could live with switching back to the prior tab after the dialogue is dealt with.
>Oh, and the bugzilla search is crap.  440060 was mine.  I DID search on "any of
the words" "cookie focus tab" and didn't find this bug.

I think that's because the default search parameters do not search for WONTFIX bugs.  But that's getting off subject. Sorry.



One more vote in favor of bringing back the FF2 behavior.  Jumping between x number of tabs when the cookie dialog pops up is VERY annoying.  One of the reasons I kept using FF2 instead of using FF3 beta.  This should be a setting in about:config.


adding another vote. i hadn't searched out the bug in R3 because i had simply assumed such a glaring issue was fixed with the release.

i don't see why the FF2 behavior is NOT modal... when i open a background tab (or in my case - around 10 tabs before the pages respond) and then get prompted i can NOT click or do anything.. it would appear to me that FF2 cookie dialogs WERE modal...

switching to the tab to switch back is confusing and seems 'extra work'.  

also a point i didn't see here is that i would bet that anyone who has gone out of their way to set the "ask me every time" option are NOT confused when they are prompted for cookies on 'hidden' tabs...  these people understand why and where the dialog is 'really' coming from.


Add another vote for this being horribly annoying.

Yes, I know that the default behavior is not "ask me every time" for cookies, but I think there are a lot of people who use that (in my case I only allow some cookies but try to disallow everything I can).

I commonly open a number of links from one page in new tabs.  FF2 just popped up the cookie dialog but left the focus on the current tab.  That worked fine (although I see how it could be confusing about what cookie were with what tab).  In FF3, I effectively can't open multiple tabs in the background because each one changes my tab focus.  Its bad enough that I am contemplating uninstalling and getting FF2 back.  I would welcome a plugin or config setting to fix this.

If we must change the focus with each new dialog, I think the best idea listed here is to have the tab focus return to the current tab after the dialog is responded too.

P.S. - I agree with the search being bad - it took a lot of searching to find this.  Had I not assumed that this surely annoyed other people too (an therefore someone would have already filled a bug), I would have made new one.
Here is another vote to restore the FF2 behavior, or at least make it an option.  The tab focus should not be changed when opening a new tab in the background.  The reason one opens a tab in the background is because they do not want to see that tab yet.  Having to accept or deny a cookie immediately is understandable so there are not a lot of connections open, but do not switch focus of the tabs.  If someone wanted to be looking at that tab now they would not have opened it in the background.
Ouch!  I thought my honeymoon with FF3 would have lasted longer.  This new "behavior" is a deal breaker for me.  I open way too many background tabs to have my currently focused tab snatched out from under me for EVERY cookie.

Any extensions around that correct this?

:-(
If you are capable of doing it, try opening 'n' different windows at once which all require cookies...  The modal windows will pop up but they will all be shown on the last tab that 'steals' the focus...

so effectively this is exactly the same behavior as FF2 with the caveat that it moves the focus to whichever tab steals focus last.

That seems to be inconsistent with wanting the dialogs on the tabs they are 'for' doesn't it?

I often open 5-10 windows from busy social networking sites which spin and spin and finally when they connect i get deluged with dialogs from all these different sites.

I went to google and searched for 'sales' and opened the first 5-10 at once. I attached a screen cap....
This is a blocker for me.

As implied above, the real solution is to re-think how this is handled so that the pop-up is replaced by an in-tab dialogue bar message.  Since cookies block further loading, this is a problem.  My suggestion is to create a new behaviour for cookies: auto-reject, but put a dialogue bar message up notifying the user, and giving the option to allow cookies in the future.  In the rare cases where that breaks something, the user can just hit reload.

But until a solution is implemented, it should revert back to the firefox-2 behaviour.
> In the rare cases where
> that breaks something, the user can just hit reload.

This is no solution because first of all many sites put many cookies, how would you tell which is the 'important' one?

The solution is pretty straightforward, bring back the old behaviour using a setting in about:config . Doing so will satisfy those that use this feature and your - not so successful - initiatives will not be totally lost!
Is anyone opposed to the idea of replacing the "ask every time" option with a "downgrade-to-session by default" option?  In particular, is there a need for a "reject completely by default" option?
I find this newer behavior // greatly hinders multi-tab browsing.  Unfortunately even /more/ than the cookie-dialogue-in-current-tab ff2 behavior.

ideal would be cookie notices as passive in nature like plugin/popup notices, or even just waiting in their respective tabs until user focus.  An auto-rejection after delay could work well.  The immediate user action should not interrupted.  If I pop open 5 tabs and begin an ongoing action in one tab -- I don't want any notices from other tabs to interrupt, it can wait.  This type of passive denial or stay-in-your-own-tab behavior seems easily compatible with both ff2/3.

Short of that, if this bug is wontfix -- then effort should be refocused on a valid workaround path: plugin, about:config, etc.  Revert to "ff2" behavior is better than current, though short of fully passive.
100% agree with Michael Waggoner; the current behaviour is more intrusive and disruptive than FF2 was and needs to be fixed.  As an end-user, I *like* being able to pick and choose what servers are and are not allowed to set cookies; disabling that option is not an acceptable workaround to me.

Having the cookie dialog be attached to the tab in question (much like the pop-up blocker) would be fantastic.  Is there an add-on that enables this, if the core developers aren't going to fix the problem?
(In reply to comment #51)
> Is anyone opposed to the idea of replacing the "ask every time" option with a
> "downgrade-to-session by default" option?  In particular, is there a need for a
> "reject completely by default" option?
> 

Could you elaborate?


Stealing some of this from http://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&forumId=1&comments_parentId=68123#threadId68322:

"
The requests to set cookies are perfectly clear: "www.cookiesetter.com (or whatever) wants to set a cookie," so it's not clear what advantage you're even supposed to get from having your reading interrupted.

When I set pages to load in the background, I want them to load in the background.
"

Is there a fix going to be made to revert to FF2 behaviour or is this showstopper going to be kept as 'wontfix'?  The idea of switching to the tab requesting the cookie and then switching back when you either accept/deny the request isn't going to work, imagine you open 8 links and you flip back and forward 32 times because each page wants to set 4 cookies, it will be insane.
I've come up with a fairly acceptable workaround; disable all cookies in the main preferences, then use CS Lite <https://addons.mozilla.org/en-US/firefox/addon/5207> to selectively whitelist servers I want to allow cookies from.
I don't want to have to whitelist. I want to deal with requests on the ad hoc basis - I'm glad that you have found it an acceptable workaround but that is not something that will work for me and others - the point that I agree with Alex G is: "I *like* being
able to pick and choose what servers are and are not allowed to set cookies;
disabling that option is not an acceptable workaround to me."

I don't want to change this into a forum topic, so I will just say that I want to basically go back to ff2 behaviour without having to either blanket reject or blanket accept cookies and then whitelist manually.

Right - have I missed something?

Can't the dialogues come up when you click on the tab?

If not, can we please (pretty please!) go back to the old behaviour, with an about:config switch?


So... 

It won't be fixed because:

1) We're all too dumb to figure out that cookie requests may be coming from the page we just opened in a new (backround) tab. We need to be shown the page, just in case we've forgotten that we clicked a link to it 3 seconds ago.

2) The users who habitually open dozens of links all at once in new tabs > the users who open links one or two at a time as they go along.

3) Because there's a work around that involves neutering cookie permissions options and either default accepting all or none. 

Yep, I'm convinced. 

We are planning on fixing this.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee: nobody → jonas
Status: REOPENED → NEW
>1) We're all too dumb to figure out that cookie requests may be coming from the
>page we just opened in a new (backround) tab. We need to be shown the page,
>just in case we've forgotten that we clicked a link to it 3 seconds ago.

I think you're missing the point of the security fix: most of the time, a dialog is coming from where you expect (e.g. the current page or a page you just opened), but in an attack scenario it is coming from somewhere you do not expect.

It's hard for me to imagine someone trying to attack the cookie-acceptance dialog that way, though, so maybe switching isn't appropriate for that dialog.

I still think it would be better to (1) nuke this feature entirely in favor of a good non-modal interface or (2) switch back to the tab after you dismiss the dialog.  But reverting to the Firefox 2 behavior doesn't seem too dangerous, and seems like a reasonable thing to do for Firefox 3.0.x.
I'm glad to know there is a fix planned. Thank you.

If it switched back to the tab it had stolen focus from once the dialogue was completed, it would still be annoying but a lot less so.

That said, I still don't understand how showing us the page helps us tell the difference between legit cookie requests and stuff like embedded advertising cookies or stat counters. I've occasionally opened pages and had five or six cookies from various places try to set themselves. 

Or were you meaning an out of the blue request? Where the user has not actually loaded a page, but a cookie is requested as part of an exploit? Because with the prefetch feature turned on, (and it seems to be on by default) I was getting cookie requests from pages not even opened anyhow. Mostly stuff turned up in Google searches and from websites linked by the website I was viewing. Cookie dialogue from unexpected places is apparently part of the normal operation of the browser. 

Possible better behaviors

1) wait until the tab is switched to ask about cookies
2) the cookie dialog can open in front of the tab that is current being browsed
and list the the number and title of the tab that is asking to set the cookie.
Another vote to fix.  FF2 behaviour greatly preferable to FF3 behaviour.
I would argue this is somewhat more severe. When a page has a frame or other element that reloads or updates frequently, it can keep asking for more cookies progressively, every couple seconds if it feels like. While this might be required for a particular function, it means that any other tab in that firefox window is essentially useless.

Alternatively (and more commonly) a single page may load many cookies from several different sites. If the page takes a minute or so to load everything, it can be stealing focus quite frequently for an annoying period of time.

I love the idea of using a bar like the remember-password UI for this, it'd make a lot more sense, at it would maintain the tie-in between the tab and the contents of that tab, without interfering with other pages.
I'd like this changed as well.  The new system clearly is a mistake leading to unpleasant user experience.

I've been waiting patiently for this to be fixed and am massively disappointed to see that it wasn't immediately recognized as bad behavior.  I've actually been using FireFox less because of it.

The new behavior creates an experience that is similar to pop-ups.  If you remember, pop-up blocking was one major reason FireFox got attention early on.
There are several other ways this can be implemented besides changing the focus to the tab. 

1. You can use the drop down dialog bar that you use when a plug-in is missing.
2. As others have said, only display the dialog when "you" focus on the tab.
3. Have a container at the bottom that will cache the cookie requests. You could then put buttons for "Allow All", "Block All" and buttons for "Allow/Block" for selected cookie requests.

In any event, the current functionality annoys me every single day.... 

Please change this as soon as possible.
I see this bug has no assigned milestone or priority.  Just how hard IS IT to get the behaviour changed back to FF2's ?

This annoys the snot out of me on a daily basis.

As a prior comment has said it doesn't even do what it was intended to !  Open a number of tabs rapidly where each will cause a cookie confirmation dialogue and they all end up displayed on the LAST tab that grabbed focus for the purpose.

So can we PLEASE have a "fix it back to FF2 behaviour for now" put in for whatever the next security/bugfix release is ?  I'm getting sick and tired of waiting for something to be done about this.

This bug is now over 8 months old.
agreed... agreed.. agreed...  can we at least get some love from a dev/project manager/ANYBODY FF related on this issue?

It's annoyed me enough to not use FF3...  Maybe I'll check out Safari.  Apple's desire to install software on my machine is only SLIGHTLY more annoying than this bug...
i've written up a wiki page that collects together some ideas for improving the cookie prompting situation. since there are many people cc'ed here that use this feature, your input on use cases and proposed solutions would be helpful. the wiki page is at:
https://wiki.mozilla.org/Cookies:prompting_ui

i've also posted to mozilla.dev.apps.firefox to start a discussion there. either of these places are suitable for discussing this feature, and are certainly better than this bug.

(this particular bug, on restoring firefox 2 behavior for modal dialogs, is already slated to be fixed - the wiki page is about future enhancements to the prompting situation, since now seems to be a good time to talk about it. please don't bring up this particular bug in that discussion.)
When Firefox 3 was first released this tab focus issue became the subject of several discussions in several forums of Mozillazine. One has been continually posted to every few days since then by a new user who finds this feature disruptive and counter productive. Please read the post to see how other users feel about it. A simple course of action would be to create a switch in Tools>Options that would allow users to turn the feature on or off at the user's discretion.

Firefox 3 Allow Cookie prompt steals tab focus
http://forums.mozillazine.org/viewtopic.php?f=38&t=681175&p=4173895#p4173895
This behavior even goes so far as to grab focus from other applications, which is doubly frustrating. Biggest reason I've got to not use firefox.
Grrrr...

This bug is getting extremely annoying!

Is this gonna be fixed, or are you just gonna let it linger?
ok so i don't know how i got upgraded (must have clicked the wrong button on the REALLY annoying popup that tells me to upgraded every 6.2 seconds) but now one of my machines has FF3 on it and still this issue isn't fixed...

while we debate about the "right" way to fix this... 

JUST PUT BACK THE FF2 FUNCTIONALITY as a stop gap.. i mean really - this is infuriating - and ridiculous...

thanks...
A similar, related problem is bug 434712, where when you're in Organize Bookmarks, if you single click on a bookmark you get a cookie acceptance dialog because it's accessing the site under the covers. Apparently something called "micro-summaries" is responsible.
Still exists in the new release.  Marvelous.  This is amazingly annoying every single day.
It seems to me that the decision the developers have to make is actually quite simple. Either:

1. you no longer think the "ask me every time" cookie functionality is valuable, and then the new tab-fronting behavior is OK, or

2. you want to keep the "ask me every time" functionality, in which case the tab-fronting behavior is unacceptable, and the user must be able to shut it off.

Here is a simple example of why the cookie "ask me every time" feature and the tab-fronting behavior doesn't work:

- Use any search engine to get a list of search results links

- User [ctrl]click to open several of the search results links in new tabs

- experience the confusion as you try to read any site (or even continue to read the search results list) while the new tabs open.

Please change this (whether you decide it was a bug or a feature :-)!
I would have to agree with many of the posters in this thread that this problem is annoying as all get-out.


I can reproduce the bug in this fashion:


 1. In "Privacy" options, set the Cookie options as:

    [x]  Accept cookies from sites

        [ ]  Accept third-party cookies

        Keep until:  [ask me every time]


 2. Close all tabs (to start with a clean slate).


 3. User "Clear Prive Data..." to delete all
    cookies from your browser.  For purposes
    of this discussion, make especially sure
    you have NO cookies set for Twitter.


 4. Open a static, relatively cookie-free page, such as
    Google, in the first tab:

        Tab #1 = http://www.google.com/


 5. Open a "sets a cookie according to a timer" page,
    such as this URL at Twitter:

        Tab #2 = http://search.twitter.com/search?q=3g+iphone+reception


 6. Switch to Tab #1 (the Google tab).


 7. Wait 30 seconds to 1 minute.


 8. Twitter will want to set a cookie, with
    data similar to this one:

        Confirm setting cookie

        The site search.twitter.com wants to set a cookie.

        [ ]  Use my choice for all cookies from this site

        [Hide Details]  [Allow]  [Allow for Session]  [Deny]

        Name:      _search_twitter_sess
        Content:   [some session string]
        Host:      search.twitter.com
        Path:      /
        Send For:  Any type of connection
        Expires:   at end of session


    Firefox will automatically move focus from
    Tab #1 (the Google tab) to Tab #2 (the
    Twitter tab) when the cookie dialog box
    is displayed.


 9. Leave "Use my choice..." unchecked and click
    the [Deny] button.


10. Click on Tab #1 to switch focus back to
    the Google tab.


10. Goto Step 7.


The sudden change of tab focus caused by the appearance of the cookie dialog box is visually startling and interrupts my wetware processing of the data on-screen.


I vote that the cookie dialog box/tab focus behavior be changed back to that exhibited by Firefox 2.0.0.x.
Could someone from Mozilla please give us an update as to whether this is even being worked on?  This bug has been around for almost a YEAR now, and there is OBVIOUS USER DISSATISFACTION with Firefox's current behavior.  Yet the bug report is still "new" (not even "open"), there is no target milestone, and the last update from the assigned developer was four months ago, saying "We are planning on fixing this."  Less planning, more fixing plz.
I'd like to stronly second the proposal to go back to the old behaviour.
As it is, the cookie popup feature makes Firefox 3 pretty much unusable
for Google search pages, for instance.

The dangers of associating the popup with the wrong window in your mind
are far less than the nuisance of not being able to skip through a
page full of links and selecting the right ones.
> The dangers of associating the popup with the wrong window in your mind
> are far less than the nuisance of not being able to skip through a
> page full of links and selecting the right ones.

Further to this, because the pop-up is for content you're not currently looking at, the current behavior runs a risk of accepting/denying cookies for a site completely accidentally, if the user is typing on an input form on the previously focused tab. This behavior can consequently break user's expectations of how their privacy settings work, and if the "use this decision for all cookies from this site" check-box is on, can accidentally persist indefinitely, causing a further privacy leak, or crippling websites that rely on cookies.
(In reply to comment #86)

> Further to this, because the pop-up is for content you're not
> currently looking at, the current behavior runs a risk of
> accepting/denying cookies for a site completely accidentally,
> if the user is typing on an input form on the previously
> focused tab.

For the use case described above, "keyboard inertia" would likely cause a typical user to keep entering at least a few keystrokes ***even after the cookie dialog is displayed***.  Since people very often do not respond to changes in their environment "instantaneously", the automatic shift of tab-focus from the current tab to the cookie-requesting tab does little (nothing, IMHO) to alleviate the problem of miskeying "selector/button" shortcuts in a cookie dialog box.

> This behavior can consequently break user's expectations of how
> their privacy settings work, and if the "use this decision for
> all cookies from this site" check-box is on, can accidentally
> persist indefinitely, causing a further privacy leak, or crippling
> websites that rely on cookies.

Granted, but I would bet that most of the people who go through the effort of changing their default cookie settings are well aware of the related privacy and functionality implications.

The default cookie settings were selected to meet the expectations of the large majority of "Joe Average" users (for lack of a better term).  Most of the people in this category are looking for a fast, easy-to-use, stable browsing experience, and do not want to be troubled by a bunch of "annoying" dialog boxes every time they load a page.

However, people who take the time to change their cookie settings are usually (pre-)conditioned to expect numerous cookie dialogs, and from multiple pages.  They are thus more aware of their browsing "environment", actually take time to read the cookie dialogs, and proceed in a more methodical manner.  Also, if they do happen to make a mistake in answering a cookie request, they are apt to notice the resulting difference in page "behaviour" very quickly.

Therefore, for the minority in the second category, this "automatic shifting of tab focus to the page requesting a cookie" behaviour is quite superfluous.
> the automatic shift of
> tab-focus from the current tab to the cookie-requesting tab does little
> (nothing, IMHO) to alleviate the problem of miskeying "selector/button"
> shortcuts in a cookie dialog box.

This is the behavior of firefox right now, which is exactly my point.

> Also, if they do happen to make a mistake in answering a cookie request,
> they are apt to notice the resulting difference in page "behaviour" very
> quickly.

Mark me down as a datapoint against this. With the myriad of ways that websites use cookies for trivial tasks these days, I've found it pretty easy to get websites into inconsistent states precisely because a tab steals focus to show me the cookie dialog, the checkbox is on, and the 'deny' button is hit, sometimes fast enough that I don't realise it's happened until the website starts misbehaving and I spend non-trivial time sorting it out.

Please fix this issue, or remove the cookie prompt dialog from the general UI preferences. Either it's good enough to keep, or broken enough to make it an enable-at-your-own-risk about:config option. Right now it's the latter.
(In reply to comment #29)
> Created an attachment (id=321734) [details]
> Dialog bar proposal
> 
> Proposal to unify all modal dialogs into a per-tab 'dialog bar'. 

Excellent concept; I hope the developers give it serious consideration.

However, it would probably also be a good idea to give the user some feedback within the confines of the actual tab itself that the page within said tab is requesting attention.

For example, the mini web-page icon that is displayed to the left of the page title within the tab could be replaced by a mini "cookie question-mark" icon of some kind, thereby indicating to the user that the page is waiting for a decision by the user.

Once the user answers the "cookie question", the mini web-page icon in the tab would be restored.

Also, how would you propose to handle a page that "fires a volley" of cookies?  Should the cookie notification bar grow in size, display all waiting cookie requests, and add new requests in the queue to the bottom of the list (i.e., oldest on top)?  Or should new cookie requests be queued up, with only one request displayed at a time?  (Personally, I would prefer the first method.)
I CONTINUE to fail to understand how this issue remains.  I have yet to see any compelling argument against using the FF2 behavior.

I think the biggest issue is that this bug's scope is "too big". I don't want "new UI" features like a nifty bar - I want FF2 behavior back... 

NUMEROUS bugs have been resolved duplicate as this bug but I don't think they are actually duplicates. This bug is asking for some "fancy" resolution to the problem.  That's just fine and dandy but it muddies the waters.

I put this bug in to hopefully get a more narrow focus on the problem.. Maybe, maybe not: https://bugzilla.mozilla.org/show_bug.cgi?id=461759
(In reply to comment #90)

> I CONTINUE to fail to understand how this issue remains.
> I have yet to see any compelling argument against using
> the FF2 behavior.
> 
> I think the biggest issue is that this bug's scope is
> "too big". I don't want "new UI" features like a nifty
> bar - I want FF2 behavior back...

While many people agree with you that FF2's cookie handling style is preferable to the current behaviour (myself included), and would be perfectly acceptable as a short-term fix, some others also believe that it would be in the Community's best interest to unify notification behaviour, as this would result in:

 1. a smaller, more compact, reusable codebase; the
    notification code used for "blocked pop-up
    window" messages could be abstracted and re-used
    for cookie notification.

 2. a more consistent user experience; Firefox would
    become easier to use because users would quickly
    learn to look in the same place for notifications.

 3. a less obtrusive cookie management system; a user's
    train of thought would no longer be broken by a
    tab-switch caused by a cookie request originating
    in a different tab.
(In reply to comment #92)
>  1. a smaller, more compact, reusable codebase; the
>     notification code used for "blocked pop-up
>     window" messages could be abstracted and re-used
>     for cookie notification.
no arguments. however the current method of presenting certificates could arguably then also be a good candidate. (sadly - this is also 'broken' but it's at least 'broken' the way FF2 was.  it presents the certificate challenge on the tab opener and does not steal the focus)

>  2. a more consistent user experience; Firefox would
>     become easier to use because users would quickly
>     learn to look in the same place for notifications.
possibly - though as other users point out people who decide which cookies they want set aren't likely to be slow to pick up however the UI works.

>  3. a less obtrusive cookie management system; a user's
>     train of thought would no longer be broken by a
>     tab-switch caused by a cookie request originating
>     in a different tab.
the tab switch is the actual bug and really this is the crux of my position.  if a stop-gap patch were to be applied which merely puts the modal on the tab/window opener this bug arguably wouldn't exist.

i'm all for fixing this 'right' but i'm also for fixing it 'now' because it's been an issue for almost 1 full year now and is a real nuisance for many people who choose what cookies to save.
Developers PLEASE READ!

Since the current behavior (switch-tab-on-cookie-dialog) is really annoying me 
these days, I've taken the time to search the web and found that it's not just 
me but a large number of users who feel the same. 

Now what drives me crazy is that it takes ONE year of discussion on the 
bugzilla without a result. I read though it and the wiki and it just blows 
my mind out. 

Why? Because the solution is simple: 

> Just don't switch tabs for cookie dialogs. There is no alternative. 

Point A: USER PERSPECTIVE: 
From the user perspecitve, there is no reason whatsoever to show the tab 
which tries to set the cookie. 
  1. The cookie dialog says precisely which server and which domain is  
     affected - so no reason to look at the tab. 
  2. Cookies from advertisers, tracking services and simular usually come 
     from completely different servers than the one the user typed into the 
     address bar. My decision on whether to accept the cookie or not solely 
     depends on the content in the cookie dialog (domain, cookie name) and not 
     at all on the tab displayed. 
  3. The fact that switching tabs disrupts the user much more than merely 
     showing the cookie dialog is not disupted by anyone. 
  4. As pointed out by several comments above, the current behavior does not 
     even show the correct tabs in all circumstances which makes it even worse 
     since it seems you cannot trust the tab displayed anyway. 

Point B: FEATURE PERSPECTIVE / ALTERNATIVES DON'T WORK:
  1. Showing in-window dialogs like the "remember password" or "install addon" 
     does not work since it would completely undermine background loading: 
     The reason is that the cookie accept/reject decision has to be made 
     immedately before subsequent requests are sent to the server. Hence, the 
     browser has to wait for user interaction before proceeding to load the 
     page. 
     Now, if the server does not wait and assumes reject, it ends up with 
     tons of different session cookies in the same session. If it does wait, 
     background loading is undermined because the user has to change to the 
     tab in question and press the accept/reject button. 
  2. Switching tabs forth-and-back merely for the cookie dialog is feasible but 
     also annoying. As pointed out above, the web page content is pretty 
     irrelevant for the accept/reject decision. 

Point C: DEVELOPER PERSPECTIVE
Simply not switching tabs is easiest to implement. All other approaches (async 
loading, additional dialog on the top like "remember passwords" etc.) are  
either more complicated to implement or no improvement for usabality at all. 
An additional config flag whether to switch tabs or not makes sense since it 
seems that people disagree about whether tabs should be switched or not. 

Regards,
Joe
Well, folks, what does it take?

Let's consider the unarguable data:

1.  Everyone who posts thinks this behavior is abominable, and that's putting it mildly.

2. "Everyone who posts" is now legion--not just here but on othher bug reports, forums, and suchlike.

3.  The claimed purpose and benefit simply doesn't exist: the collection just all lands on the last new tab, so *absolutely nothing* is accomplished by this behavior unless but a single new tab is opened (in which case there can be zero doubt about who's aking anyway.)

4.  All this has been the case for a very, VERY long time.

5.  Nothing is fixed, and there seems no clue if it even *will* be fixed, much by when.

So, again: what does it take?  Comment #16 notwithstanding, it is not the job of users to figure out how something can be done: it is their job to let the designers know when there is a severe problem needing fixing, and this they--we--have done.

What next?
Slashdot, reddit, digg, letters to infoworld, eweek, whatever.  If the moz devs are going to ignore their own bug reports, maybe we can get some external attention on it.
<p><script src="http://slashdot.org/slashdot-it.js" type="text/javascript"></script></p>
<p><a href="http://www.reddit.com/submit" onclick="window.location = 'http://www.reddit.com/submit?url=' + encodeURIComponent(window.location); return false"> <img src="http://www.reddit.com/static/spreddit7.gif" alt="submit to reddit" border="0"/></a></p>
Just another "please fix it" - those who want to be prompted for every cookie usually have a pretty good idea which tab the dialog is for. Maybe you can add something to the dialog to indicate which tab, or that the cookie was not generated from the current tab.

Switching tabs unexpectedly is highly disruptive, especially when a page has an automatic refresh which generates a change to an existing cookie, and YET ANOTHER tab switch.
I'm guessing they don't care to fix this. It's almost been a year. I'm going to stop pushing firefox to my clients until this is resolved. Absolutely ridiculous that they can't fix such a simple thing like this in a years time.
*sigh*

Another version of FF released today... my excitement was palpable! Could it be?! Would this bug got fixed?!

Naaah... too much to ask. I guess this bug will be with us forever. Apparently, Mozilla doesn't think this is a bug... whoever decided to insert this "feature" is protective of his "baby", and his wishes are more important than ours!
After dealing with this for one year I have officially stopped using firefox and removed firefox links and recommendations from all the websites I run and design.  I have never had an experience where an app that I used daily became too frustrating to use because of one change.
From Comment #62 (2008-06-24 00:19:25 PST), I quote: "We are planning on fixing this."

Some 145 days, 2 hours, and 20 minutes have elapsed since that message was posted.  Would Mr. Sicking, or anyone from Mozilla, care to enlighten us as to what time scale was encompassded in "are planning"?

We only ask because we want to know . . . .
Attached patch Fix. — — Splinter Review 
This removes the parent argument to the window opening code, which means no switching tabs or windows or anything when this dialog is opened, which I think is what we want for this particular dialog.
Attachment #348694 - Flags: superreview?(jonas)
Attachment #348694 - Flags: review?(jonas)
Comment on attachment 348694 [details] [diff] [review]
Fix.

Please add a comment about why we pass in null here.

r/sr=me with that change.
Attachment #348694 - Flags: superreview?(jonas)
Attachment #348694 - Flags: superreview+
Attachment #348694 - Flags: review?(jonas)
Attachment #348694 - Flags: review+
Attached patch With comment. — — Splinter Review 
We should take this for 1.9.1 (and 1.9.0.x too), just look at the number of complaints in this bug. This only changes a feature that's disabled by default. 'Nuf said.
Attachment #348703 - Flags: superreview+
Attachment #348703 - Flags: review+
Attachment #348703 - Flags: approval1.9.1?
Attachment #348703 - Flags: approval1.9.0.6?
Attachment #348703 - Flags: approval1.9.0.5?
"fix" might be a little strong. It's a good idea, and it'll make a big difference if it restores the Firefox 2 behavior. But a proper solution will still have to avoid the dialog box stealing the focus as well.
Comment on attachment 348703 [details] [diff] [review]
With comment.

Approved for 1.9.0.5, a=dveditz for release-drivers
Attachment #348703 - Flags: approval1.9.0.6?
Attachment #348703 - Flags: approval1.9.0.5?
Attachment #348703 - Flags: approval1.9.0.5+
Checked fix into 1.9.0 branch.

Changing assignee assuming Johnny will check in his own patch for mozilla-central once the tree reopens.
Assignee: jonas → jst
Keywords: fixed1.9.0.5
Finally!!!

Just compiled xulrunner 1.9.0.4 with the patch and works like f2, not changing tab!
Attachment #348703 - Flags: approval1.9.1? → approval1.9.1+
Attached patch For checkin. — — Splinter Review 

    
    

    
  
A fix?! Yay!

Now how does a typical FF user like me get that bit of code into my browser?

    
    

    
  
Either download a 3.0.5 nightly, or wait until this bug is marked FIXED and download a nightly 3.1 build. Or wait until 3.0.5 is released at which point you'll automatically be notified and upgraded.

    
    

    
  
Thanks Jonas!

    
    

    
  
Pushed http://hg.mozilla.org/mozilla-central/rev/ec97a4036c9a
Status: NEW → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED

    
    

    
  
I read it's fixed finally. Very nice, thanks!

    
    

    
  
After reading the long comment thread to figure out the official behavior for the fix, my head is spinning. :-)

This is verified fixed in 1.9.0.5 using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5pre) Gecko/2008120105 GranParadiso/3.0.5pre.

When the tab is opened in the background, focus is *not* given to it. The cookie prompts appear in the current foreground tab. If this is somehow not correct, say something quickly!
Keywords: fixed1.9.0.5 → verified1.9.0.5

    
    

    
  
I think the ultimate long-term fix everyone would like, would be for cookie dialogs to stay attached to their background tab, which would not gain focus.  This is the same model used by the pop-up blocker, and by the plug-in finder.

However, given the choice between going back to the FF2 behavior on the next release (what you wrote above, Al), and having to wait another year, PLEASE PUSH THE SHORT-TERM FIX!!

Thanks!

    
    

    
  
It is already in the build. It will be in 3.0.5.

    
    

    
  
I just verified this was not fixed yet in 3.0.4 and is fixed in 3.0.5 build.
I began to wonder if I needed to find a new browser, since Firefox 2 was going to no longer have security fixes and Firefox 3 had so many show stopping issues.

With this change and TabMixPlus supporting Firefox 3, the major issues stopping me from using Firefox 3 are now resolved.  I am finally able to use Firefox 3 as a functional browser.

    
    

    
  
Excellent news.  Now if someone would just fix but 442033, I could switch to version 3.

    
    

    
  
really? You shrink your window < 400px in width on such a routine basis that bug 442033 becomes a show-stopper?  I guess if you have a lot of addons that put icons in the location bar the clipping width might be wider.

    
    

    
  
May I kindly ask if this fix in ff 3.0.5 is related to this problem (which I only noticed after updating to 3.0.5):

http://forums.mozillazine.org/viewtopic.php?f=38&t=1014605

Thanks.

    
    

    
  
Yes. Please open a new bug, mark it blocking this one and cc me and the asignee of this bug

    
  
Depends on: 471640

    
  
Keywords: fixed1.9.1

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: