The URL chrome://.../inspector.xul is displayed at the bottom of the browser window when hovering over tabs in the inspector panel

VERIFIED FIXED in Firefox 50

Status

P1
normal
VERIFIED FIXED
2 years ago
4 months ago

People

(Reporter: pbro, Assigned: miker)

Tracking

({regression})

Trunk
Firefox 51
regression
Dependency tree / graph

Firefox Tracking Flags

(firefox47 unaffected, firefox48 unaffected, firefox49 unaffected, firefox50 verified, firefox51 verified)

Details

(Whiteboard: [reserve-html])

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

2 years ago
str
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.
Whiteboard: [devtools-html] [triage]

Updated

2 years ago
Blocks: 1263741

Updated

2 years ago
Flags: qe-verify+
Priority: -- → P3
QA Contact: alexandra.lucinet
Whiteboard: [devtools-html] [triage] → [reserve-html]
See Also: → bug 987373
See Also: → bug 1193340
Blocks: 1204278
> 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.
(Reporter)

Comment 2

2 years ago
(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?
Assignee: nobody → mratcliffe

Updated

2 years ago
Status: NEW → ASSIGNED

Updated

2 years ago
Priority: P3 → P2
status-firefox47: --- → unaffected
status-firefox48: --- → unaffected
status-firefox49: --- → unaffected
Version: 49 Branch → Trunk
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.
Created attachment 8776908 [details] [diff] [review]
1287389-stop-showing-urls-on-hover.diff
Attachment #8776908 - Flags: review?(bgrinstead)
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 :)
Attachment #8776908 - Flags: review?(bgrinstead)
Created attachment 8777038 [details] [diff] [review]
1287389-stop-showing-urls-on-hover.diff

(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.
Attachment #8776908 - Attachment is obsolete: true
Attachment #8777038 - Flags: review?(bgrinstead)
(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
Flags: needinfo?(mratcliffe)
> 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.
Flags: needinfo?(mratcliffe)
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
Attachment #8777038 - Flags: review?(bgrinstead)
(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.
Created attachment 8777951 [details]
Sidebar Tab Styles.mp4

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.
Created attachment 8778211 [details] [diff] [review]
1287389-stop-showing-urls-on-hover.diff

Found an easy fix for this bug... just remove href="#" and no tooltip is shown.
Attachment #8777038 - Attachment is obsolete: true
Attachment #8778211 - Flags: review?(bgrinstead)
Attachment #8778211 - Flags: review?(bgrinstead) → review+
Keywords: checkin-needed

Updated

2 years ago
QA Contact: adalucin → cristian.comorasu

Comment 18

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

Comment 19

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/8cf31b1904af
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51

Updated

2 years ago
Iteration: --- → 51.1 - Aug 15
Priority: P2 → P1

Comment 20

2 years ago
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]
Status: RESOLVED → VERIFIED
status-firefox51: fixed → verified
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
Attachment #8778211 - Flags: approval-mozilla-aurora?
Comment on attachment 8778211 [details] [diff] [review]
1287389-stop-showing-urls-on-hover.diff

Fix for a regression, verified on Nightly, Aurora50+
Attachment #8778211 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 23

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/08fce3513fac
status-firefox50: affected → fixed
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.
status-firefox50: fixed → verified
Flags: qe-verify+

Updated

2 years ago
Depends on: 1330827

Updated

4 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.