469788 - Opening bookmark from the Dock while Camino's not active always uses a new window

Status: RESOLVED WONTFIX

(Camino Graveyard :: General, defect)

Description

[Lisa Thompson]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.6pre) Gecko/2008121500 Camino/2.0b1pre (like Firefox/3.0.6pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.6pre) Gecko/2008121500 Camino/2.0b1pre (like Firefox/3.0.6pre)

When selecting a bookmark from Camino's dock menu while Camino is not the frontmost application, the bookmark gets opened in a new window even though all "Open tabs instead of windows" prefs are checked. It would seem that at least one of the existing checkboxes -- eg. "Links that would open new windows" -- should be considered as covering this case and should be respected. 

It's not that the issue bothers me much, but it is kind of striking from the following user-experience perspective: With popups blocked and all three "Open tabs instead of windows" prefs checked, I never get more than one window in Camino (excepting javascript-generated windows; I understand those are not covered by the exposed prefs). So getting a new window from something as routine as the dock menu just *seems* like an inconsistency or oversight or something.


Reproducible: Always

Steps to Reproduce:
1. Open Prefs, click on the Tabs pane, check all boxes
2. Open Bookmark Manager, right-click on any collection that contains bookmarks and choose "Use as Dock Menu"
3. Switch to another application
4. right-click or click-and-hold on Camino's dock icon and choose a bookmark

Actual Results:  
Camino opens the chosen bookmark in a new window


Expected Results:  
Camino should open the chosen bookmark in a new tab


Reference to related forum thread with comments from Uncle Asad: http://forums.mozillazine.org/viewtopic.php?f=12&t=994425

Comment 1

[Christopher Henderson]

This looks like the culprit:

MainController.mm:729
// note that [NSApp mainWindow] will return NULL if we are not frontmost

which causes MainController.mm:863
BOOL openInNewWindow = (browserWindowController == nil);

to be YES;

I shall investigate further.

Comment 2

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

If we need to consult a preference, I think in this case we should hono(u)r the "Links from other applications" tab-vs-window preference. It's most analogous in this case (even though it's different from what we do in the app-is-active case) and prevents potentially destructive behavior (replacing the current page by accident when you can't see what it is because Camino's in the bg).  I don't know how the codepath goes here, though.

I've tweaked the summary to better describe what the "bug" really is; I do think that's a bug, though I don't know whether what's described already is the best way to fix it.

Comment 3

[Chris Lawson (gone)]

Why doesn't |activateIgnoringOtherApps| get us to a point where we have a non-null [NSApp mainWindow] prior to the loadBookmark: call (MainController line 1656 at the moment, in the |openMenuBookmark:| method)?

(I'm looking into this now, but if someone comes up with a reason, feel free to speak up.)

Comment 4

[Chris Lawson (gone)]

(In reply to comment #2)
> If we need to consult a preference, I think in this case we should hono(u)r the
> "Links from other applications" tab-vs-window preference.

I have a patch that does this, but it opens new tabs in the background, which just feels *weird*. My gut says they should open in the foreground, but I'll defer to the rest of the team.

Comment 5

[Chris Lawson (gone)]

Ugh. This bug is a mess :-p

Here are all the possibilities I see...

  * When Camino is in the foreground:
    1) Open a single bookmark from any menu (including the Dock menu)
    2) Open a folder from any menu (including the Dock menu)
    3) Open a tab group from any menu (including the Dock menu)

  * When Camino is in the background:
    4) Open a single bookmark from the Dock menu
    5) Open a folder from the Dock menu (results in a submenu, so it's impossible to open a folder all at once, which makes this just a sub-case of (4))
    6) Open a tab group from the Dock menu (shows in the menu as a single bookmark, no submenu)

All menus are identical when Camino is in the foreground. Our current behaviour there is fine and shouldn't change.

The only menu accessible when Camino is in the background is the Dock menu. When opening a single bookmark, we want to do the following:

  a) bring Camino to the foreground;
  b) open the link in a new {tab|window} (depending on prefs) in the foreground (regardless of prefs, IMO; see comment 4)

When opening a tab group, we want to do the following:

  a) bring Camino to the foreground;
  b) open the tab group in new {tabs|windows} (depending on prefs) in the foreground (again, regardless of prefs, IMO)

However, if any of the URLs we're opening are already open, it seems to me like it'd be nice to treat background Dock menu URLs the same way we treat external app URLs -- find and reload if already open, so we don't end up with lots of new tabs for no reason.

I don't really know what users would expect here, because I hardly ever use the Dock menu for anything, but treating these URLs exactly like links from external apps when Camino's in the background at least "feels" right to me.

Comment 6

[philippe (part-time)]

(In reply to comment #5)

> I don't really know what users would expect here, because I hardly ever use the
> Dock menu for anything, but treating these URLs exactly like links from
> external apps when Camino's in the background at least "feels" right to me.

I'd expect the same behaviour as links from external apps (I don't use the Dock menu much either).

Comment 7

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]