167245 - Tabs opened from external application should ignore "load in background" pref

Status: RESOLVED FIXED

(Camino Graveyard :: Tabbed Browsing, defect, P3)

Description

[cmiller]

When you have Chimera set to load new tabs in the background, this preference
also affects tabs that have been opened by external applications. This is
confusing and annoying.

The point of "load page in the background" within the browser is so that you can
keep reading one page while the other loads. This makes no sense when a page is
loaded from another application, because an application-switch occurs the moment
you click the link. Since you were switching from another app, the least likely
thing that is relevant to you is the page that was last front-most on the browser.

Comment 1

[Mike Pinkerton (not reading bugmail)]

smfr worked on this logic

Comment 2

[Scott Houchin]

I disagree with the reasoning here for some situations, and in fact I am about
to enter a similar bug report for new windows.

However, wouldn't this be 

The application logic is unfortunately more complicated than just whether it
comes from another application or not. For example, I have a shell/appelscript
that lets me enter commands in terminal to open browser windows. If I want to
open serveral sites, I can enter a command like "www maccentral,macintouch,xf,exf"

Yes, I want Navigator to come to the front, and I want the first site in my list
to come to the front. However, I want all other sites in my list to come to the
back. I realize that this is rather complicated logic to put into preferenes, so
I'm not really expecting other it to get implemented. I would be just as happy
with Navigator opening new windows triggered by other applications in the
background.

However, here's a suggestion for a starting point if the Navigator implementors
wanted to take a shot at this:

Two preference fields:
- If Navigator is the active app when the request is received (regardless of who
generated the request), should windows/tabs be opened in the front or back
- If Navigator is not the active app when the request is received (regardless of
who generated the request), should windows/tabs be opened in the front or back

I think this would probably make everyone happy, as the question of whether
Navigator is the active app probably correlates very well with the question of
whether the user is currently viewing a web page or not, and thus lets the user
decide whether new requests should interrupt the current viewing or not.

Comment 3

[Shoshannah Forbes]

Well, somes did open a bug (bug 185870), complaining that your RFE is working...
:-)

Comment 4

[cmiller]

This bug is unrelated to 185870. That is about opening new windows. This is
about giving focus to tabs.

Comment 5

[Ludovic Hirlimann [:Usul]]

isn't this a dup of 155132 ?

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #5)
> isn't this a dup of 155132 ?

No, bug 155132 is about what Camino should do (open new tab or not, etc.) when
it encounters protocols that lauch external apps.  This is about what Camino
should do when external apps call Camino :)

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 8

[Aaron Peterson]

Tabs opened from external application should ignore "load in background" pref...

or how about having it's own pref, where load in new tab in background is an
option, along with load in new tab in foreground, and load in new window is an
option, and load in current window

Comment 9

[L. H.]

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

Comment 10

[Simon Fraser [no longer active]]

Any objections if I fix this?

Comment 11

[Simon Fraser [no longer active]]

Attachment: Patch

Comment 12

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 193670 [details] [diff] [review]
Patch

looks good, and has the added side effect of fixing the support pages from
loading in the bg.

r=pink

Comment 13

[Simon Fraser [no longer active]]

Fixed on trunk and branch.