Clicking "view pocket list" in the library panel, moves the current page away and navigates to the pocket website. I assumed that the pocket list would remain in a sidebar or a panel, just like my synced tabs. Given that this seems not trivial, I suggest opening this in a new tab instead of overriding the current page.

The behaviour is the same as that of the item in the bookmarks menu, so I don't think this is specific to the item we added in the library. You can get it to open in a new tab by ctrl/cmd-clicking (or using the middle mouse button, if you have one) it, or open in a new window with shift-click. It's completely consistent with other items in the UI that open a page. I do understand that it's not obvious from context that it will open a page. I think the behaviour will feel more obvious/natural when we implement a list of recent activity (downloads, bookmarks, history) in the library that all open in the current tab by default (well, except downloads, of course) as well (with similar modifier behaviour). See bug 1354536 for that. In the meantime, I don't think this urgently needs addressing, but ymmv. Aaron, does that sound right?

(In reply to :Gijs from comment #1) > I do understand that it's not obvious from context that it will open a page. Yep, that's my main point. I was expecting a list and not a page. It makes sense that pages open in the same tab, of course. > In the meantime, I don't think this urgently needs addressing, but ymmv. Sure, just wanted to drop this here for your consideration :)

Yeah, I think loading this on some other surface (e.g. the sidebar) will be what we want to do down the road. The biggest problem I have with the current behavior is (at least in my case) I can't navigate back by simply clicking the back arrow; the Pocket website only refreshes. I'd suggest having the 'View Pocket List' button open a new tab for now since it's not terribly clear what's going to happen and that way we won't cannibalize their current page.

Commenting on this ticket after reading the Photon Engineering newsletter #8. I added the sidebar button to my toolbar to quickly pull up the toolbar and immediately compared it to the Library button that was already on my toolbar, and the entries in the library menu and the sidebar menu are virtually identical except for the lack of a "View Pocket List" in the sidebar. Obviously, it feels weird to have an entry in the sidebar panel for Pocket if there is no sidebar optimized view for the pocket list, but as it is, in order to have the Pocket list available to me, I have to have both the library and sidebar toolbar icons present (say if I dislike the precise interaction required for mega-menu/menu type UI that is entailed by the library menu). Since Mozilla has bought Pocket, this begs for increased integration between Firefox and Pocket -- I'm not sure that this means that the Library/menu item (on alt or macOS) ought to be a submenu opening inside of the bookmarks menu (since Pocket is like a super bookmark) -- perhaps with the first item in the Pocket menu/sidebar being the existing "View Pocket List" entry (that opens in a new tab, as suggested by Frederik). We have precedent in the bookmarks submenu in the Library UI for "View Bookmarks Sidebar" -- adding a Pocket submenu in Library, along with two new items (sorted first) for "View Pocket List" and "View Pocket Sidebar" (separated by horizontal dividers preceding the actual Pocket list), allows for users to access the Pocket web UI, along with a new Pocket sidebar. Either way, the lack of the sidebar entry/view in the Firefox sidebar feels like like an intended behavior and more like "unfinished" integration. The same applies to the fact that in the Library menu, the other items are all top level menu items that open submenus.

After testing the new on-boarding ("Nightly is all new. See what you can do!") on about:home (or about:newtab), specifically ... On-boarding modal => Library => Show Library Menu => Library => View Pocket List ... it was irritating to get navigated away from the on-boarding tour. On one profile I checked it with, I was logged in to Pocket already, making it hard to simply navigate back with left-swipe on my track pad (or pressing CMD + left-arrow, or using additional mouse button to navigate back/forward) as there is a redirect happening. Getting redirected from https://getpocket.com to https://getpocket.com/a/queue/ causes an additional entry in the browser history making it impossible to navigate one single history item back. The user has to now to actively use the long-click on the browser back button in order to move two steps back to the on-boarding tour.

See also bug 1354046?

bug 1386831 covers creating a list, but that's complex and might not make 57, so here's a patch to at least not be terrible.

Comment on attachment 8900498 [details] Bug 1375806 - don't overwrite the current non-empty tab when viewing pocket list, https://reviewboard.mozilla.org/r/171876/#review177646 looks reasonable.

Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/35a7d4fdba0b don't overwrite the current non-empty tab when viewing pocket list, r=mixedpuppy

I can see this issue in Nightly 56.0a1 (2017-06-23) (64-bit) in 64bit Linux. I can verify that this issue is fixed in latest Nightly 57.0a1 Build ID 20170826100418 User Agent Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0