Closed Bug 1286844 Opened 4 years ago Closed 4 years ago

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

Categories

(DevTools :: Console, defect)

50 Branch
defect
Not set

Tracking

(firefox50 verified, firefox51 verified)

VERIFIED FIXED
Firefox 51
Tracking Status
firefox50 --- verified
firefox51 --- verified

People

(Reporter: Fanolian+BMO, Assigned: bgrins)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

Attachments

(5 files)

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.
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
Has STR: --- → yes
Component: Untriaged → Developer Tools: Console
Attached image 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.
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.
Blocks: 1281732
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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
Are we going to get this fixed now that 50 is going to Aurora?
Flags: needinfo?(bgrinstead)
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
(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
Flags: needinfo?(bgrinstead)
Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED
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.
Attachment #8777070 - Flags: review?(jsnajdr) → review-
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/
Attachment #8777070 - Flags: review- → review?(jsnajdr)
Good catch, pushed up a new version that handles both cases
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)
Attachment #8777070 - Flags: review?(jsnajdr) → review+
Pushed by bgrinstead@mozilla.com:
https://hg.mozilla.org/integration/fx-team/rev/d912055f8e8a
Add [title] for source location onto the inner ltr element;r=jsnajdr
https://hg.mozilla.org/mozilla-central/rev/d912055f8e8a
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
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
I can verify too.
Status: RESOLVED → VERIFIED
Can we get this uplifted to 50, Brian?
Flags: needinfo?(bgrinstead)
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]:
Flags: needinfo?(bgrinstead)
Attachment #8777070 - Flags: approval-mozilla-aurora?
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+
Attachment #8777070 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Depends on: 1299482
Attached image 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)
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.
(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.
Flags: needinfo?(magicp.jp)
Because, the tooltip works on first hover if apply rtl in RTL locales. And also fix arrow.
Flags: needinfo?(magicp.jp)
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.
(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.
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
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
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.