1286844 - Tooltip in Web/Browser Console does not show on first hover

Status: VERIFIED FIXED

(DevTools :: Console, defect)

Description

[Fanolian]

Attachment: Tooltip not showing on first hover

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20160714030208

Steps to reproduce:

Please refer to attached video.

1. In a new profile, open Web Console or Browser Console.
2. Hover on a link in middle or right column.


Actual results:

Tooltip does not show on first hover.
To work around this, I have to move cursor away from the link and hover on it again; or just hover on another link in the same column.

If I hover on links in another column, the bug is reset and I have to hover twice on the link to get the tooltip.

Comment 1

[Fanolian]

From mozregression:
Last good Nightly: 2016-07-01
First bad Nightly: 2016-07-02
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fdcee57b4e4f66a82831ab01e61500da98a858e8&tochange=39dffbba764210b25bfc1e749b4f16db77fa0d46

Comment 2

[Fanolian]

Attachment: Tooltip text alignment

Perhaps it is related. Tooltip text in the right column, if it is too long, is aligned to the right. It was aligned to the left before 2016-07-02 build.

Comment 3

[Brian Grinstead [:bgrins]]

Very weird.  The [title] attribute is set on the .frame-link-source so I don't know why it wouldn't show up on the first hover.  It likely started happening after bug 1281732 but I really don't know why that would be.    This seems like a platform bug unless if we are doing something unusual with the elements / attributes - I don't see anything that looks out of the ordinary.

Comment 4

[atlanto]

Attachment: Tooltip has an extra "/" at the beginning

If frame-link-source is just a web site url, tooltip is not correct.
BTW, this bug occurs at least on Windows10, Manjaro Linux 16.06, LinuxMint 17.3/18.

Comment 5

[atlanto]

My workaround with Stylish add-on. (it solves first-hover and aligning issues)

@namespace url(http://www.w3.org/1999/xhtml);
.stack-trace .frame-link-source,
.message-location .frame-link-source {
  direction: ltr!important;
}

@https://hg.mozilla.org/mozilla-central/file/9ce60fab89f5/devtools/client/themes/webconsole.css#l113

Comment 6

[Andrew Overholt [:overholt]]

Are we going to get this fixed now that 50 is going to Aurora?

Comment 7

[Brian Grinstead [:bgrins]]

I think Bug 1290056 was very close to fixing this, but we might need to move the 'title' attribute onto the new inner element introduced there

Comment 8

[Brian Grinstead [:bgrins]]

Attachment: Bug 1286844 - Add [title] for source location onto the inner ltr element;

Review commit: https://reviewboard.mozilla.org/r/68670/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/68670/

Comment 9

[Brian Grinstead [:bgrins]]

(In reply to Andrew Overholt [:overholt] from comment #6)
> Are we going to get this fixed now that 50 is going to Aurora?

Sure, should be an easy uplift

Comment 10

[Jarda Snajdr [:jsnajdr]]

Comment on attachment 8777070 [details]
Bug 1286844 - Add [title] for source location onto the inner ltr element;

https://reviewboard.mozilla.org/r/68670/#review65978

<p>Cool, so the title attribute is also affected by the RTL property and must be moved to the LTR element. And "/" is another character that gets shuffled around in the RTL mode. I see the patch fixes the problem, at least for the isLinkable=true case.</p>
<p>I have absolutely no idea why the tooltip is not shown on first hover (probably some platform bug?), but the patch fixes that, too.</p>

::: devtools/client/shared/components/frame.js:233
(Diff revision 1)
> -        title: l10n.getFormatStr("frame.viewsourceindebugger", tooltip)
>        }, sourceInnerEl);
>      } else {
>        sourceEl = dom.span({
>          className: "frame-link-source",
>          title: tooltip,

The case with "isLinkable==false" is not handled properly - the outer span still has a "title" attribute, and the inner span has a "title" with incorrect value.

If the source is not linkable, the title shows the full URL, if it is linkable, it shows the full URL with a "View in debugger ->" prefix.

Comment 11

[Brian Grinstead [:bgrins]]

Comment on attachment 8777070 [details]
Bug 1286844 - Add [title] for source location onto the inner ltr element;

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/68670/diff/1-2/

Comment 12

[Brian Grinstead [:bgrins]]

Good catch, pushed up a new version that handles both cases

Comment 13

[Jarda Snajdr [:jsnajdr]]

Comment on attachment 8777070 [details]
Bug 1286844 - Add [title] for source location onto the inner ltr element;

https://reviewboard.mozilla.org/r/68670/#review66282

Looks good (if the test are all passing again on try)

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/fx-team/rev/d912055f8e8a
Add [title] for source location onto the inner ltr element;r=jsnajdr

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/d912055f8e8a

Comment 16

[Nawaf Chowdhury Akash]

I have successfully reproduced this bug with nightly 50.0a1 (2016-07-14) on windows 10, 32 bit.


The bug’s fix is now verified on Latest Nightly 51.0a1.

Build ID:20160805030444.
User Agent:Mozilla/5.0 (Windows NT 10.0; rv:51.0) Gecko/20100101 Firefox/51.0

Comment 17

[Fanolian]

I can verify too.

Comment 18

[Andrew Overholt [:overholt]]

Can we get this uplifted to 50, Brian?

Comment 19

[Brian Grinstead [:bgrins]]

Comment on attachment 8777070 [details]
Bug 1286844 - Add [title] for source location onto the inner ltr element;

Approval Request Comment
[Feature/regressing bug #]: 1281732
[User impact if declined]: Tooltip on source links in console messages doesn't show up on first hover, and is misaligned
[Describe test coverage new/current, TreeHerder]: There's a small addition to a test case to make sure the [title] attribute is being added to the correct element
[Risks and why]: The risk is limited to the console tab inside the devtools toolbox.  It's a small change, moving an attribute from one element to another
[String/UUID change made/needed]:

Comment 20

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8777070 [details]
Bug 1286844 - Add [title] for source location onto the inner ltr element;

Fix was verified on Nightly, recent regression, Aurora50+

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/4306add4a88a

Comment 22

[magicp]

Attachment: In-RTL-locales.png

I confirmed on a latest Nightly (Build ID: 20160831030224) in Arabic. This bug is not fixed in RTL locales.
- Tooltip in Web/Browser Console does not show on first hover
- The arrow "→"　direction is wrong (This cannot confirm using Force RTL)

Comment 23

[magicp]

Still affects in 50/51 with RTL locales
- Tooltip in Web/Browser Console does not show on first hover - This bug
- The arrow "→"　direction is wrong (This cannot confirm using Force RTL) - filed to Bug 1299482

I think this bug will be fixed if Bug 1299482 was fixed.

Comment 24

[Jarda Snajdr [:jsnajdr]]

(In reply to magicp from comment #23)
> Still affects in 50/51 with RTL locales
> - Tooltip in Web/Browser Console does not show on first hover - This bug

Just to be sure: the behavior where the tooltip doesn't show on first hover really still persists in RTL locales?

I know there are still issues with the content of the tooltip - wrong RTL content, arrows... But that's another issue.

Comment 25

[magicp]

Because, the tooltip works on first hover if apply rtl in RTL locales. And also fix arrow.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

This bug had multiple verifications after the fix landed. For the sake of sane issue tracking, whatever problems remain should be spun off to a new bug rather than leaving this bug in an inconsistent and confusing state.

Comment 27

[magicp]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #26)
> This bug had multiple verifications after the fix landed. For the sake of
> sane issue tracking, whatever problems remain should be spun off to a new
> bug rather than leaving this bug in an inconsistent and confusing state.

You are right. So a new bug should be filed before change status to verified. But nobody filed it.

Comment 28

[Carmen]

I was able to reproduce the issue using the affected build (nightly 50.0a1 - 2016-07-14) on Win 10 Pro x64

I verified the fix on the latest Aurora 50.0a2 (2016-09-15) using Win 10 Pro x64, Ubuntu 16.04 LTS x64 and Mac OS X 10.12 Sierra Beta

Comment 29

[Carmen]

The fix is also verified on Firefox Beta 50.0b4 across platforms: Windows 10 Pro, Ubuntu 16.04 LTS x64 and Mac OS Sierra 10.12.1

Comment 30

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

Thank you, Carmen!