STR: - open the inspector on any page - put your mouse over one of the tabs in the inspector sidebar - wait for a bit AR: at the bottom-left corner of the browser viewport, the link to inspector.xul is displayed (a chrome:// URL). ER: nothing should happen, this is an internal URL that should not appear where people expect content URL to be shown. Most probably comes from the fact that bug 1259819 now uses HTML <a> elements inside each tab. Not sure why links are used by the way, they don't hold any href, so other inline elements would probably work.

> Not sure why links are used by the way, they don't hold any href, so other inline elements would probably work. We have a similar issue with the console in Bug 987373. We are using links so they are keyboard focusable: https://bugzilla.mozilla.org/show_bug.cgi?id=987373#c33. If you come up with a replacement here that are keyboard accessible I'd like to also use it in console output.

(In reply to Brian Grinstead [:bgrins] from comment #1) > If you come up > with a replacement here that are keyboard accessible I'd like to also use it > in console output. Yeah, I expect that we'll have a bunch of places in devtools where this happens. Bug 987373 seems to be about the "click to inspect" icon which, really, should be a <button>. There are a few valid cases in devtools where we should use <a> links, things that really have href attributes and that aim at opening new tabs for example. Like opening a resource from the netmonitor, or a script from the console, etc... These things should be links, and having the browser status bar show for them sounds fine. It actually is expected by users. In all other cases, I think <button> would be better, or maybe a <span> with a tabindex?

So having looked into this we are *very* consistent with showing the full URL in a tooltip whenever we hover a URL. This is great because we only ever show one tooltip at a time so it prevents the URL from appearing at the bottom left of the content window. I have replaced the anchor tags in the sidebar tabs with spans, checked in all three themes and can confirm that they all look identical. We should run this through try before landing this though as it could cause issues with tests that e.g. switch tabs in the sidebar... I doubt it though.

Comment on attachment 8776908 [details] [diff] [review] 1287389-stop-showing-urls-on-hover.diff Review of attachment 8776908 [details] [diff] [review]: ----------------------------------------------------------------- ::: devtools/client/shared/components/tabs/tabbar.css @@ +15,5 @@ > border-inline-start-width: 0; > } > > +.tabs .tabs-navigation .tabs-menu-item span:focus { > + outline: none; Why was this outline removed? Seems unrelated to the rest of the patch ::: devtools/client/shared/components/tabs/tabs.css @@ +1,3 @@ > /* vim:set ts=2 sw=2 sts=2 et: */ > /* This Source Code Form is subject to the terms of the Mozilla Public > + * License, v. 2.0. If span copy of the MPL was not distributed with this 'a' changed to 'span' on this line :)

(In reply to Brian Grinstead [:bgrins] from comment #6) > Comment on attachment 8776908 [details] [diff] [review] > 1287389-stop-showing-urls-on-hover.diff > > Review of attachment 8776908 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: devtools/client/shared/components/tabs/tabbar.css > @@ +15,5 @@ > > border-inline-start-width: 0; > > } > > > > +.tabs .tabs-navigation .tabs-menu-item span:focus { > > + outline: none; > > Why was this outline removed? Seems unrelated to the rest of the patch > The key word is is "seems." The original selector never worked... probably related to the old -moz-outline bugs (-moz-outline overrides outline and is applied differently to spans than a tags). Without this change when you click on a tab it has a dotted outline... we never wanted or had this. > ::: devtools/client/shared/components/tabs/tabs.css > @@ +1,3 @@ > > /* vim:set ts=2 sw=2 sts=2 et: */ > > /* This Source Code Form is subject to the terms of the Mozilla Public > > + * License, v. 2.0. If span copy of the MPL was not distributed with this > > 'a' changed to 'span' on this line :) Fixed.

(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #7) > > Why was this outline removed? Seems unrelated to the rest of the patch > > The key word is is "seems." The original selector never worked... probably > related to the old -moz-outline bugs (-moz-outline overrides outline and is > applied differently to spans than a tags). Without this change when you > click on a tab it has a dotted outline... we never wanted or had this. OK, so there was no outline when it was an <a> tag but it became visible when it was a <span>?

ni for Comment 8

> OK, so there was no outline when it was an <a> tag but it became visible when it was a <span>? Exactly... that is why I needed to hide it again.

Comment on attachment 8777038 [details] [diff] [review] 1287389-stop-showing-urls-on-hover.diff Review of attachment 8777038 [details] [diff] [review]: ----------------------------------------------------------------- This needs rebasing Also, I've just checked the current UI and there *is* an outline, with the following STR: Open inspector Click on Rules -> outline is visible on rules tab Press left / right arrow to switch tabs -> outline remains visible on selected tab Same happens if you tab into rules filter box then shift+tab back

(In reply to Brian Grinstead [:bgrins] from comment #11) > Comment on attachment 8777038 [details] [diff] [review] > 1287389-stop-showing-urls-on-hover.diff > > Review of attachment 8777038 [details] [diff] [review]: > ----------------------------------------------------------------- > > This needs rebasing > > Also, I've just checked the current UI and there *is* an outline, with the > following STR: > > Open inspector > Click on Rules -> outline is visible on rules tab > Press left / right arrow to switch tabs -> outline remains visible on > selected tab > > Same happens if you tab into rules filter box then shift+tab back A bunch of accessibility stuff has been added and the CSS is completely rewritten. Not bad for a single days bitrot!

How about using <button> instead of <span> for a11y ?

(In reply to Tim Nguyen :ntim (use needinfo?) from comment #13) > How about using <button> instead of <span> for a11y ? That would make sense, particularly from an a11y standpoint... will do.

These are the current styles.

I noticed that the a11y guys have added a bunch of aria stuff to make these tabs accessible. Apparently, we *should* be using links because that allows users to use left and right arrows to navigate the tabs. Whatever we do we need to ensure that we don't break this model. Marco Zehe says that the best keyboard interaction model is this: 1. Left and Right arrow keys should move focus to the new tab, but not yet select it. 2. Space should actually perform the hiding and un-hiding of the tab panels and adjust the aria-selected attributes. This is how Mac OS X applications with multiple tabs usually do it, for example many multi-tab panels in the System Preferences. This makes sure the user can change focus multiple times without each focus change triggering a dynamic update and possibly network traffic. Only an explicit step to select a tab should then actually trigger the change, and traffic. Mouse or touch can trigger both at the same time. 3. Tab should immediately move to the first control within the tab panel. It should skip over the remaining tabs.

Found an easy fix for this bug... just remove href="#" and no tooltip is shown.

Pushed by cbook@mozilla.com: https://hg.mozilla.org/integration/fx-team/rev/8cf31b1904af Stop showing URLS on devtools hover r=bgrins

I have successfully reproduce this bug on firefox nightly 50.0a1 (2016-07-18) with windows 7 (32 bit) Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0 I found this fix on latest nightly 51.0a1 (2016-08-09) Mozilla/5.0 (Windows NT 6.1; rv:51.0) Gecko/20100101 Firefox/51.0 Build ID : 20160809030200 [bugday-20160810]

Comment on attachment 8778211 [details] [diff] [review] 1287389-stop-showing-urls-on-hover.diff Approval Request Comment [Feature/regressing bug #]: 1259819 [User impact if declined]: comment 0 [Describe test coverage new/current, TreeHerder]: in nightly, verified fix [Risks and why]: low, one line change [String/UUID change made/needed]: no

Comment on attachment 8778211 [details] [diff] [review] 1287389-stop-showing-urls-on-hover.diff Fix for a regression, verified on Nightly, Aurora50+

I reproduced this bug using Fx 50.0a1, build ID: 20160718081125, on Windows 10 x64. I can confirm the bug is fixed, I verified using Fx 50.0a2 build ID: 20160817004002 , on Windows 10 x64, Ubuntu 14.04 LTS and Mac OS X 10.9.5.