New issue
Advanced search Search tips

Issue 675252 link

Starred by 1 user

Issue metadata

Status: Archived
Owner:
Closed: Sep 19
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Feature



Sign in to add a comment

FEAT REQ no urls in the back button right click menu

Reported by eng.a7ma...@gmail.com, Dec 16 2016

Issue description

UserAgent: 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
 

Comment 1 by ajha@chromium.org, Dec 19 2016

Labels: M-55 prestable-55.0.2883.87
Labels: -M-55 M-57 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Considering the above issues as Feature-Request and marking it as untriaged for further triaging from dev team.

Thanks!
Labels: -Type-Bug Type-Feature
Components: Privacy
Cc: msramek@chromium.org maxwalker@chromium.org
Max, WDYT?
Owner: maxwalker@chromium.org
Status: Assigned (was: Untriaged)
I support this, as I have needed this in the past.
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?
1) URLs.png
89.3 KB View Download
2) Tooltip.png
217 KB View Download
3) Status Bar.png
127 KB View Download
4) Overlap.png
381 KB View Download
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.

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 :)

Cc: est...@chromium.org
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.
Status: Archived (was: Assigned)
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