718140 - Option to open feed items (e.g., RSS) directly in default browser

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, enhancement)

Description

[Michael Sirolly]

User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7

Steps to reproduce:

Double-click any item from a feed (e.g., Atom, RSS...) in a Thunderbird "Subscription" account.


Actual results:

After double-clicking, the feed item will open in either a new tab, a new message window or an existing message window, per "Tools > Options > Reading & Display > Open messages in:"

To jump to the webpage associated with the feed item, the user then clicks the "Website" link in the header section of the tab/window where the feed item opened.

At that point, the content associated with the feed item will be open in both a Thunderbird tab/window and also a browser tab/window. (Which ultimately means two tabs/windows to close, and the clutter is multiplied by however many feed items the user is in the habit of opening and then viewing in a browser rather than Thunderbird.)


Expected results:

When double-clicking a feed item, would like the option to open its "Website" header field directly in my default browser, without first spawning a new Thunderbird tab/window.

Akin to having an option for default functionality something like one or more of the following...

   "View > Feed Message Body As... > In Browser"

   secondary mouse click feed item > context menu: "Open Message in Browser"

   "Tools > Options > Reading & Display > Open feed message in: > Browser"

Of course, the content of the feed item itself and the content of the linked "Website" header field are technically two distinct things. But I'm rarely interested in the feed item's own content, separate from the linked "Website" field. Also, the feed item's own content would still presumably be visible/previewed within Thunderbird's Message Pane (it that's open), and could be opened in a Thunderbird window using a secondary mouse click and choosing "Open Message in New Tab/New Window" from the context menu.

Comment 1

[alta88]

fixed in Bug 596234.

there is not a menuitem (yet) but you can set the pref rss.show.content-base to 3, and an enter/dbl click will open the page in the default browser.

Comment 2

[Michael Sirolly]

Thank you, thank you, thank you for implementing this. Words can't adequately convey the sheer miraculousness of this enhancement! (Delayed response in part because I'm on the release channel, and had to sit tight through TB 15.x and 16.x until I could try this in TB 17.)

After trying this setting for a couple months, I have but one suggestion: after opening a feed item this way, it should be marked as read. (Either immediately or shortly thereafter. Blindly marking the feed item as read would likely provide 99 percent of the utility in a few lines of code, versus some elaborate technique that actually tried to cross-communicate with the browser.)

Please let me know if I should file that suggestion separately, or if it warrants changing the status of this entry.

Another possible reason for filing a new entry, or changing this entry's status: as a reminder to consider promoting this enhancement for exposure somewhere in TB's interface, along the lines of "View > Feed Message Body As > In Web Browser." (Of course, if it were up to me, I'd make it the freakin' default! For new users anyway.)

Other devs and project contributors who use feeds heavily should try out this setting for a little while. I think it streamlines the whole feed-reading experience, particularly for a power user. Some arguments in advocacy:

* Feed items for blog posts and social media updates frequently summarize Web content elsewhere, and then link to it. When a Thunderbird user follows such a link, the link opens in the browser anyway, rather than continuing in Thunderbird tabs or windows. And if the original feed item was opened in a separate Thunderbird tab or window, it remains open, later requiring extra housekeeping by the user to close both the browser tab/window and the Thunderbird tab/window. Multiply this across dozens, hundreds, thousands of feed items skimmed by heavy users of feeds.

* When a user opens, say, a dozen-plus feed items, it may increase the likelihood of a crash. If the browser crashes but is subsequently relaunched, it generally restores (or offers to restore) all of the tabs and windows that were open at the time of the crash. Thunderbird currently doesn't restore tabs and windows lost due to a crash. 

* While most feed items render nearly the same in Thunderbird versus a browser, a small percentage display better in a browser, while the reverse is not true. (Perhaps the web page requires an account log-in or some other dependency on cookies or add-ons/extensions/plug-ins, or renders incorrectly in Thunderbird due to sniffing or targeting of best-known browsers.)

* It helps consolidate history and cookie data in the browser, and enables management of content and privacy settings in fewer places.

* Particularly on small screens (e.g., laptops), it may be more convenient than viewing/previewing feed items in the limited confines of the Thunderbird message pane.

* It may make it easier to bookmark a feed item for later reading, particularly through certain cloud services, or repost the feed item to social networking sites using browser add-ons. Browsers may also sync bookmarks and open tabs/windows across devices, so users can pick up their reading elsewhere.

* It may help limit total memory consumption and processor demands across open Thunderbird and browser tabs/windows, and their retinue of active add-ons/extensions/plug-ins.

Again, really appreciate your work on the mechanics of Thunderbird's feed-reading engine. While I can name any number of email clients that largely match Thunderbird's email feature set, few competitors approach Thunderbird's industrial-scale feed-reading capabilities. It may be Thunderbird's most distinctive and compelling "hidden" functionality... a sleeper hit, of sorts!

Comment 3

[alta88]

thanks for the comments.  there isn't any reason why feeds in Tb can't blow away any existing standalone feed reader.

the item is (should be) marked read on selection, per delay pref, as for any other content type.

as for menuitems to promote power options, that was nixed by UI review in bug 728563.  i don't think the reviewer spent any time on it, is probably not a feeds power user, and may not even be a Tb feeds user.  but that's how it goes.  there is/was an active policy to remove/reduce any UI that might be confusing to the average user.

btw, there is another hidden option to open the link in a browser merely on selection of the item. rss.message.loadWebPageOnSelect, set to 1.

Comment 4

[Michael Sirolly]

To clarify, re: when a feed item is opened by double-clicking, "the item is (should be) marked read on selection, per delay pref, as for any other content type."

If the Message (Preview) Pane is open, at even a minimal size, the feed item ^does^ get "marked read on selection, per delay pref."

But if the Message (Preview) Pane is closed/disabled, the feed item is never marked read, regardless of whether the user single-clicks to select it, or double-clicks to open it in the default web browser.

Which is to say (not having seen the code myself), the "mark as read" event appears tied to Thunderbird rendering the feed item on its own -- which in this scenario it never does -- rather than tied to the user action of selecting or opening the feed item.

(In this scenario, with the Message Page closed/disabled, I wouldn't expect the feed item to be marked read simply by single-clicking to select it, but I would expect it to marked read immediately or shortly after double-clicking/typing [CTRL]-[O]/etc. to open the feed item in the default web browser.)

I've replicated this under both Mac OS X and WinXP. Hopefully this description makes more sense, and I readily concede it feels strange to be discussing "desired behavior" for a completely unofficial, unsanctioned, unsupported not-actually-a-feature (hemidemisemi)feature.  :-)

Comment 5

[alta88]

that is a valid point, though if 'read' means being strictly sure the item's url was rendered, it isn't possible (via reasonable means) for Tb to know that.  you can open a bug; in this case it would mean 'url sent to external browser'.