FEAT REQ no urls in the back button right click menu
Reported by
eng.a7ma...@gmail.com,
Dec 16 2016
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. open a website and navigate to create history 2. right click the navigation back button 3. hover over any history entry in the context menu What is the expected behavior? to see the full url for this entry not just the title What went wrong? no way to know the difference between different entries, specially with the same title! Did this work before? N/A Chrome version: 55.0.2883.87 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 24.0 r0
,
Dec 20 2016
Considering the above issues as Feature-Request and marking it as untriaged for further triaging from dev team. Thanks!
,
Dec 20 2016
,
Dec 20 2016
,
Jan 2 2017
Max, WDYT?
,
Jan 3 2017
I support this, as I have needed this in the past.
,
Jan 3 2017
A large part of page URLs is very long and shows technical implementation details that are not meaningful to regular users, see examples of popular sites in attachment (1). So I think generally page titles are more valuable in the navigation context menu. Ideas: A) Showing the URL in a tooltip next to each entry. Downside of this approach: we would add clutter (two information-dense overlays right next to each other), tooltips aren't ideal to present longer strings, line-breaks would make URLs hard to read, see attachment (2). Truncating URLs could help to prevent large, unreadable tooltips. B) Re-using the status bar in the bottom left of the window to display the URL. We already use the status bar to display URLs when hovering over links in the content area (attachment 3). Downside: in extreme cases where the context menu is very long and the window is very small the context menu covers the bottom left corner of the window, so the status bar wouldn't be visible (attachment 4). Maybe the existing UI logic that moves the status bar when covered (https://goo.gl/MKWi7) could alleviate this or we could fall back to a tooltip in this case. WDYT?
,
Jan 4 2017
hey max, thanks for your detailed feedback. I'm not sure if you are asking me or not but I will give my input anyway :D I suggest we leave option A and focus on B as it feels more standard and thats where I was expecting to see the URLs before I submitted the issue.
,
Jan 4 2017
I think B3 makes sense as it's an existing UI surface, and we're basically treating the "Back" button menu items the same as any other link. It's also unobtrusive and can be shown immediately (I assume B2 would require some timeout). B4 is hopefully a rare enough corner case, but I'm currently sitting at a large monitor, so I might be biased :)
,
Mar 2 2017
The tooltip seems like a fine idea to me, provided we elide it smartly (similar to how the status bar starts off elided). In the example provided, the really long URL param at the end probably provides no value to the user, just clutter. We already have code we can use to smartly choose which part of a URL to elide. Other ideas: - replace the menu entry (page title) with the URL on long hover. - put the URL in the omnibox, perhaps highlighted, a la URL suggestions you get when typing.
,
Sep 19
Archiving old bugs that have only received trivial updates for some time. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks! |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by ajha@chromium.org
, Dec 19 2016