The sidebar should be able to provide links which work like bookmarks. When the user clicks the link it should open that link in the currently active tab. There is no mechanism by which to do this at the moment: - you cannot have no target since that will load the document into the sidebar - if you specify "_blank" as a target that creates a new tab each time. Somebody clicking on several links would not likely expect this behaviour. - you cannot specify a named target since that will not activate an existing tab (thus the result may be hidden, or in a different firefox window even) Ideally it'd work however opening a bookmark works (in case that behaviour is customizable). This may not be a strictly social API question but it comes up primarily in this context.
(In reply to edA-qa mort-ora-y from comment #0) > - you cannot specify a named target since that will not activate an existing > tab (thus the result may be hidden, or in a different firefox window even) Making this work is probably the best we can do here. I'm surprised it doesn't, but maybe there's some weirdness with the isAppTab/onBeforeLinkTraversal code going on.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to :Gavin Sharp (use firstname.lastname@example.org for email) from comment #1) > (In reply to edA-qa mort-ora-y from comment #0) > > - you cannot specify a named target since that will not activate an existing > > tab (thus the result may be hidden, or in a different firefox window even) > > Making this work is probably the best we can do here. I'm surprised it > doesn't, but maybe there's some weirdness with the > isAppTab/onBeforeLinkTraversal code going on. I'm not sure what "making this work" means. If I have a html file with, eg: <a href="http://www.google.com", target="something">click me</a> Clicking the link opens a new tab as expected. Switch back to the tab with the anchor and click on it again and you can see the tab with google refresh, but it doesn't get activated. If you then open a new window and load the content with the anchor, clicking on it causes the existing tab in the other window to reload but it isn't activated. Best I can tell, all of this is independent of the isAppTab/onBeforeLinkTraversal code and things have worked like this for ages. Are you suggesting we can change the behaviour described above? I could see a case to say the tab should get activated, but can't see what makes sense in the "different window" case... Ed: I'm not sure it makes sense to replace the currently open tab as that might not be what the user expects (eg, they may have something important open and clicking on the sidebar in a moment of distraction). It *might* make sense to reuse the existing tab if the tab is already on your domain - do you think that would help?
The tab will never be on our domain as we will be linking to articles on other domains. I wonder about the named target working. What would happen if the user has two firefox windows open, obviously the new document should appear in the active firefox window. Perhaps each sidebar could use some unique target and get it to work that way. Honestly, I'm not certain what the best UX here is. It should be based on these observations: - if a user clicks on multiple links in the sidebar, they may expect only one tab to open, in particular if the flow is click link, read doc, click link, read doc, repeat. - if the user has an important page open they wouldn't expect it to be replaced by the clicked link (however, this is what happens with bookmarks, so it's not totally unexpected)
(In reply to Mark Hammond (:markh) from comment #2) > (In reply to :Gavin Sharp (use email@example.com for email) from comment > #1) > > (In reply to edA-qa mort-ora-y from comment #0) > > > - you cannot specify a named target since that will not activate an existing > > > tab (thus the result may be hidden, or in a different firefox window even) > > > > Making this work is probably the best we can do here. I'm surprised it > > doesn't, but maybe there's some weirdness with the > > isAppTab/onBeforeLinkTraversal code going on. > > I'm not sure what "making this work" means. I assumed from the quoted text that opening a targeted link from social panels didn't work. I see now that the issue being pointed out was that it does "work", but isn't useful because it doesn't select the tab that the load gets triggered in.
I'm broadening the scope of this bug to handle the general use case rather than proposing a specific solution. It seems that ideally there could be one tab in a browser window that is "dedicated" to a single social provider, and when the provider targets that tab it would be activated. I've no decent thoughts yet on how to "spell" that though, but off the top of my head, maybe a special pseudo-target called "_social"?
Summary: allow opening link in currently opened tab → allow opening link by a provider to reuse and activate a tab.
I like the idea of a "_social" target as it makes it very clear that a link from the social API is being opened. It frees me, as the provider, from having to worry about what exactly that means and allows you to change the behaviour later, or for the user to customize the behaviour.
Sorry for the bug-spam. This is a first cut at bugs that need (or potentially need) a change to the social api to be implemented appropriately.
Created attachment 689335 [details] [diff] [review] sidebar click handling I don't see any good way to handle targeted links from the social sidebar, but I did discover a click handler that is used by the web panels. I think this is the best possible solution. We could use this and have the same behavior as other web panels. The click handler adds support for target=_content which will always load in the current tab in the current window.
Attachment #689335 - Flags: feedback?(gavin.sharp)
(In reply to Shane Caraveo (:mixedpuppy) from comment #8) > The click handler adds support for > target=_content which will always load in the current tab in the current > window. Unless I misunderstand the proposal, I thought we had decided this was not the behaviour we desired - bug 808001 explicitly changed notification clicks from that behaviour to opening a new tab.
Whiteboard: [needs-api-change] → [needs-api-change][1.5]
Comment on attachment 689335 [details] [diff] [review] sidebar click handling I don't think we want to spread the target="_content" behavior anywhere further if we can help it. Supporting the rest of the contentAreaClick functionality (keyboard shortcuts for link clicks etc.) is probably reasonable. Is it currently possible to address comment 0's use case by doing something like: var w = window.open("url", "mywindow"); w.focus() or does dom.disable_window_flip get in the way? I guess it would. I'm not sure that comment 0's use case is one that we actually should support - having links override your active tab seems potentially confusing.
Attachment #689335 - Flags: feedback?(gavin.sharp) → feedback-
So what I'm thinking is: * Add that patch from Shane which adds onclick="contentAreaClick(event, true);" to the sidebar browser. * contentAreaClick() gets new code to check for 'target="_social"' (or some other attribute?). While we might be able to determine automatically the click is from the sidebar, I'm guessing we want to give providers some control over this so, eg, they can still specify target="_blank" etc? If the attribute is set, contentAreaClick() calls urlSecurityCheck(), then directly calls openLinkIn() with |where="social"|. * openLinkIn() supports this new value |where="social"|. If specified, it attempts to find a tab with an attribute |isSocialTab="true"| (or a better name?) and if found, uses and focuses it. Otherwise a new tab is created and the attribute is added. Note that this means all providers end up "sharing" the same tab - so if you switch providers, the tab used by the old provider will also be used by this provider. That seems reasonable to me in the short term, and should be easy to change without requiring providers change anything if it is a problem later. What this does *not* give us is support for window.open() with a name of "_social", but that is probably a reasonable limitation (and seems like it might be difficult to implement - IIUC, http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#3158 is where this should logically go if we needed it. Hopefully we don't :) Another thing we could consider is making this new behaviour the default for social clicks - ie, if no "target" is specified on a link, it works as described. This would mean providers get this new functionality "for free" (including existing ones, like Facebook.) If we did this, the second bullet-point above would change from "check for target attribute" to "check if there is *no* target attribute and the click event came from the social browser") Gavin - does this sound OK to you, or can you suggest someone else who could review this plan?
Sorry, I guess I lost track of this need-info somehow :/ I'd like to avoid designing a solution for this specific use case if we could avoid it - I'm not sure it's important enough to merit that.
We've had a few complaints about the "open many tabs behaviour", but not enough to state for certain it is a global problem.
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 2 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.