Closed Bug 439054 Opened 12 years ago Closed 11 years ago

A bit confusing: windows opened with window.open() open new tabs in another (parent) window (FF3RC2)

Categories

(Firefox :: Tabbed Browser, defect, P1, major)

defect

Tracking

()

VERIFIED WONTFIX

People

(Reporter: ilkkap, Assigned: mconnor)

References

()

Details

(Keywords: regression, testcase)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

This code opens a new window:

<a id="lnkIcon1Header" href="javascript:window.open('http://www.trilogica.it/','990x670','toolbar=yes,location=yes,status=yes,menubar=yes,scrollbars=yes,resizable=yes,width=990,height=670');void(0);"><br/>TriLogica</a>



The new window looks exactly like a new firefox browser.
No indications that it is a popup or anything less than a normal FF browser window.
More confusing is that any link in the popup window, that has target="_blank" does not open in that window, but in another (parent or any other if parent was closed). If the popup window is maximized, it seems that the links do not work at all, event that they are opened, but in another window.
And the window that has opened the tab does not give any feedback about it (flashing or other things)


Reproducible: Always

Steps to Reproduce:
1. Go to http://www.ikea.it (example)
2. Click on the icon ESHOP Lombardia
3. A new window opens
4. Maximize the new window
5. Go to http://www.google.it or www.live.com
6. Make sure that the preferences of the search engine are to open links in a new window (Open search results in a new browser window)
7. Search something
8. Click on the result links.. it seems that nothing happens
9. Switch to the parent window.. the links are there

Actual Results:  
I'd expect some visual hint that something has happened.
The best for me would be to open the tabs on the current (popup) window, but at least the window that opens the tabs should flash or do something to indicate that the system is working.

Expected Results:  
Anything that tells me that the tabs are getting opened.
Hmm, maybe the fix for bug 377551 was overzealous?
Blocks: 377551
Duplicate of this bug: 440671
Testcase from duplicate:
https://bugzilla.mozilla.org/attachment.cgi?id=325947
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
OS: Windows Vista → All
Hardware: PC → All
This bug "brakes" an intranet application we developed opening new windows as dialogs. Requesting blocking 1.9.0.1
Flags: blocking1.9.0.1?
I have the same problem. A new window opened with window.open is not awarded the status of "The most recent window" and tabs open in another window.
This used to work OK in Firefox 2. This breaks my intranet application also. 
For all the testcases on this bug, when I click on the link to open a new window, the new window doesn't have the bookmark toolbar so technically it isn't a normal browser window.

I don't really know why the bookmark toolbar is hidden though.
Severity: normal → major
Enn: any thoughts?
Flags: wanted1.9.0.x?
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1+
Keywords: regression
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.1-
Flags: blocking1.9.0.1+
It would be useful if at least tabs were allowed for 'popups' where the target window is the same as the popup.
Flags: blocking1.9.0.2?
Would be nice to have it at least configurable. See bug 377551 comment 23. Users need both behaviours, so they should be able to choose.
Hello Patrick,

In my opinion, it shouldn't be configurable. It will cause more trouble then solving the problem and also adding additional learning curve to the end-user. The solution should be either restore the old behavior or let coder decide the behavior.
The best solution would be to undo this change. The user expects a new tab to be opened in the browser-window which is in focus. 

In my opinion bug 377551, is no bug at all. Chromeless-windows are quite common, e.g. on online-banking sites and the decision to lock these windows out from tabbed browsing seems arbitrary and not well-founded.
Not blocking, but it's already wanted. Get a patch and we can take this in 1.9.0.3.
Flags: blocking1.9.0.2? → blocking1.9.0.2-
Duplicate of this bug: 452462
Duplicate of this bug: 453576
Flags: blocking1.9.0.3?
Again, this is not blocking. If you'd like this fixed, please get a fix on the trunk then request approval on an appropriate branch patch.
Flags: blocking1.9.0.4? → blocking1.9.0.4-
Flags: blocking-firefox3.1?
Duplicate of this bug: 458684
If someone needs to revert to the old FF2 behaviour, can try a small extension written by me, hosted, at the present, here: https://nic-nac-project.org/~kaosmos/test/Restore_Old_Link_Behaviour-0.1.xpi
(In reply to comment #17)
> If someone needs to revert to the old FF2 behaviour, can try a small extension
> written by me, hosted, at the present, here:
> https://nic-nac-project.org/~kaosmos/test/Restore_Old_Link_Behaviour-0.1.xpi

Thank you my Italian friend! It worked as it should work!!
(In reply to comment #17)
Fantastic! It works very well!!
Is it good also for FF3 linux version?
(In reply to comment #17)
> If someone needs to revert to the old FF2 behaviour, can try a small extension
> written by me, hosted, at the present, here:
> https://nic-nac-project.org/~kaosmos/test/Restore_Old_Link_Behaviour-0.1.xpi

Could you attach a patch with this fix?
To Monica Bettoli: yes, the extension works also on Linux and Mac OSX

To  José Jeria: you must consider that the behaviour of FF3 is intentional, the developers has written the code of browser.js so that you can't open in a tab a link (via javascript or from an A tag) if the window is a popup window (i.e. it's lacking in toolbar, statusbar etc). If the window is a popup window, FF3 searches for another "regular" window to open the link.

This code is at:
http://mxr.mozilla.org/firefox/source/browser/base/content/browser.js#4409

My extension rewrites the function _getMostRecentBrowserWindow in this simply way

nsBrowserAccess.prototype._getMostRecentBrowserWindow = function() {
        return window;
};

so that the links are always opened in current window.
If this strange, unlogical behaviour is indeed intentional, this actually means that Firefox is an unreliable platform to develop Web 2.0/Intranet applications for.
If at any given moment applications, developed specifically for Firefox, can simply be broken because Firefox developers, in their infinite wisdom, suddenly decide that past behaviour should be changed at any arbitrary moment in time, I cannot require users to use Firefox any more to use my applications. 
I most certainly cannot require users to download and install an additional extension to 'fix' Firefox 3 even if I appreciate the effort made to create this extension.  
Perhaps Google Chrome will become a more reliable and stable platform to develop web-based applications for.
For code change, you can see https://bugzilla.mozilla.org/show_bug.cgi?id=377551
My opinion is that the user should be able to choose the behaviour in this situation, with a preference; there are lots of preferences about "open link mode", one more wouldn't be a problem.
A trivial patch to add a preference could be (sorry but I don't know how to write a "regular" patch according to bugzilla specs):

in browser/base/content/browser.js change the line

var win = this._getMostRecentBrowserWindow();

with

var allowLinkInPopup = gPrefService.getBoolPref("browser.tabs.allowOpenLinkInPopup");
if (allowLinkInPopup)
    var win = window;
else	  
    var win = this._getMostRecentBrowserWindow();

===
in /browser/app/profile/firefox.js adds those lines

//Allow/Deny link opening in tab in a popup window
pref("browser.tabs.allowOpenLinkInPopup", false);
Duplicate of this bug: 461787
If you search Mozilla forums, you will see that this "intentional" behavior change has driven dozens of users to frustration and annoyance, if they can even figure out what has gone wrong, since the program does NOT, as previously noted, give any indication of where the new tab will appear.

The proper fix WOULD be to add something to options to let the user decide between FF2 or FF3 behavior, in my opinion. Whoever made the change was not thinking clearly about the effects on the end user experience.

David


(In reply to comment #21)
> To Monica Bettoli: yes, the extension works also on Linux and Mac OSX
> 
> To  José Jeria: you must consider that the behaviour of FF3 is intentional, the
> developers has written the code of browser.js so that you can't open in a tab a
> link (via javascript or from an A tag) if the window is a popup window (i.e.
> it's lacking in toolbar, statusbar etc). If the window is a popup window, FF3
> searches for another "regular" window to open the link.
> 
> This code is at:
> http://mxr.mozilla.org/firefox/source/browser/base/content/browser.js#4409
> 
> My extension rewrites the function _getMostRecentBrowserWindow in this simply
> way
> 
> nsBrowserAccess.prototype._getMostRecentBrowserWindow = function() {
>         return window;
> };
> 
> so that the links are always opened in current window.
It seems like some sites work better with the Firefox 3 behavior (e.g. bug 377551 comment 2, bug 377551  comment 6) and some sites work better with the Firefox 2 behavior (many of the comments here).  Hmm.

Going back to something like the old behavior might be reasonable.  For one thing, it wouldn't completely re-break the site in bug 377551 comment 6 -- yay for the fix for bug 177838!
IMHO, the real problem here/with the patch of bug 377551 is that documentElement.getAttribute("chromehidden") is not a good test to decide if a window is a popup or not. When only the Bookmarks Toolbar is missing, we can probably safely decide that the window is not a popup. I think we can replace this test with something more tolerant, we will need to decide what is the minimal set of things that shouldn't be hidden for a window to be a regular one.
The patch that was posted no longer works with Firefox 3.03!

Can anyone help? This is driving me crazy!

David

(In reply to comment #17)
> If someone needs to revert to the old FF2 behaviour, can try a small extension
> written by me, hosted, at the present, here:
> https://nic-nac-project.org/~kaosmos/test/Restore_Old_Link_Behaviour-0.1.xpi
Patches are great if all you are concerned with is your own viewing.  I'm concerned that 23% of the visitors (those who use Firefox) to my own site cannot make it run properly.  And I'm not alone.  An entire industry of photographers and artist use pop-up, full-screen browsers to display their portfolio websites.  

Firefox is ruining our sites!  HELP!
As per comment 28, we need a better test for "popup" or "not popup"; chromehidden isn't appropriate. I believe Connor had ideas for what to do, here.
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Would a decent solution be to just focus the window.open()'ed window, that IMHO would be a perfect compromise of 1) decently presenting a pop-up window that's not meant to be chromeless (instead of making the popup itself multi-tabbed, ie Firefox 2 behavior), 2) making sure the user sees this new window.

This makes sense in the flow of things as well, if we focus the opened window on the first call to window.open, why shouldn't we focus the opened window on subsequent calls?
Dear Mr. Beltzner, when can a solution to this issue be expected? We are operating the largest online-banking website in austria and we cannot recommend our users to switch from FF2 to FF3 as long as this issue has not been resolved.
It's the most notorious bug we are facing since the release. Please fix it as soon as possible...
(In reply to comment #31)
> As per comment 28, we need a better test for "popup" or "not popup";
> chromehidden isn't appropriate. I believe Connor had ideas for what to do,
> here.

If Connor has ideas for what to do here, let's let him own it.

Mike, can you please post your ideas and work on / reassign this appropriately?
Assignee: nobody → mconnor
(In reply to comment #29)
> The patch that was posted no longer works with Firefox 3.03!
> Can anyone help? This is driving me crazy!
> David

This is not correct, the extension works properly with current 3.0.x versions.
The extension even works with FF3.1beta2. Edit the install.rdf from the xpi by changing the maxVersion line to 3.1 and you are done.
Connor: I'm marking this a P1, as if we fix it, we'll want that fix for Beta 3. If you disagree with the blocking decision or prioritization, please renominate.
Priority: -- → P1
Why are people opening almost-but-not-quite full windows like this?  I don't think that's the right behaviour, and I don't understand if the "everything but the bookmarks toolbar" behaviour is something they're trying to do.

The easy workaround, for sites hitting this issue, is to add directories=yes to the window features so the bookmark toolbar isn't hidden.  I don't think people are trying to open windows that are almost, but not quite, full windows, I could be wrong.

I think the right fix may be to show all toolbars when menubar=yes and toolbar=yes.  I need to talk to the DOM guys about how this works in practice.

Opening a new link as a tab in a 400x200 window with no chrome isn't an answer, which is why we changed the behaviour.  I still don't think partially-chromed windows should be treated as normal browser windows, but obviously we need to figure out the almost-full case.  I think it's a little confusing (I've been confused about why I didn't have a bookmarks toolbar in one of my windows more than a few times) which is why I'm leaning towards changing the window.open behaviour to not do the almost-but-not-quite behaviour we're seeing here.
1/ Because we need it. When you have hundreds of rows/photos/data in a page to work with, you don't want to be bothered with neither an addressbar, a menubar, a toolbar nor a fortiori a bookmarks bar (vertical space is more important). We need a clean, empty, without toolbars of any kind, window to put our data in.

2/ As a consequence, we use this kind of window full screen, which means that if we have to process/view the data/photos/whatever in a new window, this new window HAS TO be opened as a tab in the current one (FF2 behaviour). The current default behavior in FF3.0.x (opened in the parent) is counter-intuitive and inaccessible: that regression is confusing.

3/ What I suggest is going back to the FF2 behavior and give the user the option to have (a better) FF3 behavior.

Thanks for having a look at this real pb seriously.
(In reply to comment #40)
> 1/ Because we need it. When you have hundreds of rows/photos/data in a page to
> work with, you don't want to be bothered with neither an addressbar, a menubar,
> a toolbar nor a fortiori a bookmarks bar (vertical space is more important). We
> need a clean, empty, without toolbars of any kind, window to put our data in.

In this case, you're opening a popup, not a browser window.  I think they have different use cases.  If you want another popup, you can do that.  If you want a tabbed interface without chrome, you can use any of the various toolkits out there to create your own tabbed interface.  Expecting us to revert to less-useful UI so a handful of apps don't have to find another solution isn't an answer, IMO.

> 2/ As a consequence, we use this kind of window full screen, which means that
> if we have to process/view the data/photos/whatever in a new window, this new
> window HAS TO be opened as a tab in the current one (FF2 behaviour). The
> current default behavior in FF3.0.x (opened in the parent) is counter-intuitive
> and inaccessible: that regression is confusing.

In this specific case, when you're opening a large window and using it as an app platform, you want this behaviour.  But consider an app like Pandora, which opens a small player window.  I don't want other tabs hiding the player, I don't want to have to resize that window to view the related data.  I don't want links from other apps opening in that window either.  The popup window is a child window in general, and that's how we've chosen to treat it.

> 3/ What I suggest is going back to the FF2 behavior and give the user the
> option to have (a better) FF3 behavior.

Going back to a less useful behaviour by default is only an option when the change negatively impacts large numbers of top sites.  Going back to the old behaviour would be a usability regression in most cases, so I see no compelling argument for going back to the old behaviour.

I think the best course of action is as follows:

1) File a new bug on smarter window.open behaviour (open a normal window when toolbar=yes and menubar=yes
2) Resolve this bug as WONTFIX, as this is intended behaviour, and web authors have options to control this.
Now I understand your intention, you want to have pandora always on top. But this breaks numerous websites. I doubt that it is 'smarter behavior' if a new tab is opened in a browser-window which is not focused and the window does not even get the focus when the new tab is opened. This is not what I call usability. Because you have to search the new tab in all the currently opened windows.  

Yours Harald
Not always on top.  But we should treat popup windows separately from normal windows.  The lack of focus when opening in a full browser window will be fixed in bug 445845, I agree that the lack of focusing is a bug.
filed bug 473538 to cover the "do something smarter with window.open" bit.

The rest of this is WONTFIX.
Flags: blocking-firefox3.1+ → blocking-firefox3.1-
These is objectively no difference between a popup and a normal window without all its bars/menus. So identical behaviour should apply to both (according to user choice).

>>>less-useful UI
Define less-usefull. And less-usefull for who?
Given the number of complaints in just the Mozilla forii, the less-usefull UI seems to be the current FF3.0.x one.

>>>large numbers of top sites
Thanks for reminding me that I'm not (yet) in the top 100. In case you did not see, this bug was keyworded as "regression" because it is one.

>>>In this specific case, when you're opening a large window and using it as an
app platform, you want this behaviour.  But consider an app like Pandora, which
opens a small player window.  I don't want other tabs hiding the player, I
don't want to have to resize that window to view the related data.
Given the number of complaints above, I don't think this case is specific. There are many webapps that uses multitabbed window (popup or normal). Why assume that popups are small windows?

>>>WONTFIX
Thanks for reconsidering it. 
Developers need to be able to open new window (popup or normal) not in the parent/root window (with low vertical space), but, because of the architecture of their webbapps, in the current opened window. It is the privilege of the user to decide if the new window (popup or normal) has to opened in tabs or not.
(In reply to comment #41)
> Expecting us to revert to less-useful UI so a handful of apps don't have to
> find another solution isn't an answer, IMO.

Your "less useful UI" argument seems to rely on the assertion that small "popups" (e.g. Pandora windows) are more common than large "popups" (e.g. full screen gallery browsing windows), in cases where frequent link navigation occurs. I don't think that assertion has been proven, and in fact I would kind of expect it to be the case that most link navigation in popups actually happens in large windows. I have no data to back that up, though.

Either way, as Jesse said in comment 27, we've chosen to improve some sites at the cost of others, and the decision seems rather arbitrary. Sounds like Pandora users are happy, and some web apps are broken - hard to judge how those compare to each other objectively.

Given the feedback we've heard, and the fact that it's now impossible for web apps to open un-resizable windows, I think restoring the Firefox 2 behavior is the best way forward. Users of Pandora have several options to improve their browsing experience (resizing the window, dragging out the tab) that they didn't have back in Firefox 2, so reverting this behavior isn't going to hurt them as much as it otherwise would have.
Flags: blocking-firefox3.1- → blocking-firefox3.1?
We are using a popup window to show wizards that collects data from user and at some step we give user a chance to preview the output. When user hits on preview button it opens preview in a new tab in the same popup window (FF2, not FF3). We can't embed the preview within the wizard because of dynamic nature of our wizard system.

Can anyone suggest me a MORE USEFUL UI for this case? Besides this, there are at least FIVE more cases in our application which are affected by this annoying behaviour.
(In reply to comment #46)
> (In reply to comment #41)
> > Expecting us to revert to less-useful UI so a handful of apps don't have to
> > find another solution isn't an answer, IMO.
> 
> Your "less useful UI" argument seems to rely on the assertion that small
> "popups" (e.g. Pandora windows) are more common than large "popups" (e.g. full
> screen gallery browsing windows), in cases where frequent link navigation
> occurs. I don't think that assertion has been proven, and in fact I would kind
> of expect it to be the case that most link navigation in popups actually
> happens in large windows. I have no data to back that up, though.

It has nothing to do with the size of the popup, really.  If you link to http://foo.com as an external page from your popup, without specifying size/features/etc, it doesn't make sense to open it in a crippled window.  This isn't "what happens when you click a link in the popup window" it's "what happens when you click a link that's opening a new window/tab from a popup window."  The assertion that we made in making the change is that loading a normal page is best in a window with normal UI so you can browse, well, normally, instead of having to work around a suboptimal experience (more on this below).

Users can middle-click/Cmd+Click to open a link in a tab in the same window, regardless of this behaviour, if they want that.  I don't believe opening a normal webpage in a limited-chrome window is useful, popups are inherently different UI for specialized cases (webapps, photo galleries, etc) and not for general browsing.

> Either way, as Jesse said in comment 27, we've chosen to improve some sites at
> the cost of others, and the decision seems rather arbitrary. Sounds like
> Pandora users are happy, and some web apps are broken - hard to judge how those
> compare to each other objectively.

I think any assertion of cost here is at least partially dubious.  The behaviour that the developers in question are complaining about has always depended on a pref setting, which means it can't be relied on 100% of the time in any case.  The only real cost is that if you want two pages open with full control over the browser chrome displayed, you need windows and not tabs.  What it seems like people want here is target="_tab" actually.

> Given the feedback we've heard, and the fact that it's now impossible for web
> apps to open un-resizable windows, I think restoring the Firefox 2 behavior is
> the best way forward. Users of Pandora have several options to improve their
> browsing experience (resizing the window, dragging out the tab) that they
> didn't have back in Firefox 2, so reverting this behavior isn't going to hurt
> them as much as it otherwise would have.

This is a relatively tiny amount of negative feedback, in a whole year after we made the change.  I don't think there's a strong case that we need to revert the change based on this feedback.  If we do that, you get a tab in a window with a read-only location bar, no search bar, and no back/forward buttons for a link that's _not_ a popup window.  You can resize/drag out, yes, but forcing users to do that seems pretty user-hostile, for the sake of a handful of developers.

Anyway, the short version is that we implemented a change, shipped multiple betas and a final release, and got a small volume of opposition to the change.  Reverting the behaviour because the old behaviour isn't as bad as it used to be just feels like UI churn without solid justification.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: blocking-firefox3.1? → blocking-firefox3.1-
Resolution: --- → WONTFIX
>>>This is a relatively tiny amount of negative feedback, in a whole year after we
made the change.
The turnover of browser in real business is (very) slow. Entire intranets/webapps can not be tested against every beta/new browser version. Switch to FF2 had taken many-man years of work, it is simply not realistic to do that for every browser release. I will skip the FF3 branch for the moment.
(In reply to comment #48)
> It has nothing to do with the size of the popup, really.  If you link to
> http://foo.com as an external page from your popup, without specifying
> size/features/etc, it doesn't make sense to open it in a crippled window.

Why? The "crippled" window might just be where the user wants it to load, and my point was that this is probably more likely if the window is large.

> This isn't "what happens when you click a link in the popup window" it's
> "what happens when you click a link that's opening a new window/tab from a
> popup window."

Yeah, I know, that was implicit in my reply. I don't think that changes any of my argument.

> Users can middle-click/Cmd+Click to open a link in a tab in the same window,
> regardless of this behaviour, if they want that.

Not if the links are window.opened from JS.

> I don't believe opening a normal webpage in a limited-chrome window is
> useful, popups are inherently different UI for specialized cases (webapps,
> photo galleries, etc) and not for general browsing.

You've asserted that before, but a bunch of people here and in bug 377551 disagree.
 
> I think any assertion of cost here is at least partially dubious.  The
> behaviour that the developers in question are complaining about has always
> depended on a pref setting, which means it can't be relied on 100% of the time
> in any case.

> You can resize/drag out, yes, but forcing users to do that seems pretty
> user-hostile, for the sake of a handful of developers.

As far as I can tell it's the users who are complaining, not developers. Their tabs are opening in unrelated windows by default when they browse from a not-quite-full browser window, and they have no control over it.
(In reply to comment #48)
> This is a relatively tiny amount of negative feedback, in a whole year after we
> made the change.

There's been next to no positive feedback, either. Granted, we generally tend to only hear about the negative feedback, but low feedback in general just might mean that both of these use cases are relatively uncommon.
(In reply to comment #48)
 
> This is a relatively tiny amount of negative feedback, in a whole year after we
> made the change. 

My intranet/webapps is not working well with this new behavior in FF3, we've 4 facilities (2500 users) that can't upgrade to FF3.
This negative feedback is enough?
> This is a relatively tiny amount of negative feedback, in a whole year after we
> made the change.

All our SaS (more than 3000 users Worldwile, more than 2000 just in Brazil) use the old (and, for me and most here, the good) behavior and our clients can't change to FF3 because of this. Our systems are locked to access with FF, but because of this crazy behavior we are studying to change it to Chrome or other one.
Chrome opens a tab in the main window and focuses that window.  IE7 opens a new full window.

http://steelgryphon.com/firefox2/test/window.open-test/test.html is useful for testing various permutations.

Please note that the focus issue where the window where the tab was opened was not focused has been fixed on trunk, and the fix will be in 3.1 b3.  That seems like the largest issue that was raised here.
Duplicate of this bug: 478850
> This is a relatively tiny amount of negative feedback, in a whole year 
> after we made the change.
RE: All our SaS (more than 3000 users Worldwile, more than 2000 just in Brazil)...
RE2: My intranet/webapps is not working well with this new behavior in FF3, we've 4 facilities (2500 users)...
...

> Status: RESOLVED WONTFIX 
Really, really disappointed...
the easiest way (the ignore-way) was chosen
...imagine when Google cut ties with Mozilla?
Choosing to not act is not the same as ignoring feedback.  I've listened to the rationale, found it insufficient to behave differently from other browsers or to revert what is in the general case a usability win, and marked this bug accordingly.  Just because you don't get your way doesn't mean you can claim you're being ignored.

Simply put, your choices are to a) stay on Firefox 2 forever, b) write an extension that overrides this behaviour and deploy to your affected users or c) change your application to not rely on the old and broken behaviour (and for bonus points, your application would then ideally work well in other browsers, instead of being tied to a single browser).
Status: RESOLVED → VERIFIED
I totally disagree with your choice.
Intendentedelleacque, thank you to have wrote the extension that I've installed in all or clients, this permits to our webapps to continue work correctly also with FF3.
Monica
I can understand the choice to have this behaviour as default, but I don't understand why you don't want to add a preference to revert to FF2 one, if the user prefers this.
Techincally this is trivial and there are lots of hidden preferences about much marginal points. One of the best thing of Firefox is surely its flexibility, so why are you so strinct?

@Monica: you're welcome.
The 0.1.1 version of the extension works also on Firefox 3.5 and has automatic update enabled.
The link is this : https://nic-nac-project.org/~kaosmos/index-en.html#rolb
You need to log in before you can comment on or make changes to this bug.