Closed Bug 1712669 Opened 3 years ago Closed 4 months ago

Tool-tip covered by mouse cursor when using enlarged cursor

Categories

(Core :: Widget: Win32, defect, P3)

Firefox 88
defect

Tracking

()

VERIFIED FIXED
126 Branch
Accessibility Severity s2
Tracking Status
firefox126 --- verified

People

(Reporter: hymnsfordisco, Assigned: emilio)

References

Details

(Keywords: access)

Attachments

(2 files, 1 obsolete file)

Attached image Capture.JPG

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

In windows settings, change mouse pointer size to any size 3 or higher.
Mouse over an element that has a tool-tip.

Actual results:

The offset of the tool-tip is not great enough for the larger cursor size, so the beginning of the tool-tip is covered up by the cursor and can't be read.

I can't provide a screenshot or video of this because the cursor size appears different in screen recordings. Instead, I have a picture taken of the actual screen.

Expected results:

I expected that the tool-tip should automatically offset far enough away from the mouse cursor so that it can be properly seen.

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Address Bar
Component: Address Bar → General
Component: General → Widget: Win32
Product: Firefox → Core
Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: access
Priority: -- → P2
Whiteboard: [win:accessibility]
Whiteboard: [win:accessibility]
Whiteboard: [access-s2]

The severity field for this bug is set to S3. However, the accessibility severity is higher, [access-s2].
:spohl, could you consider increasing the severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(spohl.mozilla.bugs)
Severity: S3 → S2
Flags: needinfo?(spohl.mozilla.bugs)

Hello,

I see mainly two parts here:

  1. the tooltips shown as part of the browser interface, such as when pointing the mouse to the name of a tab;
  2. the tooltips shown by the various websites being browsed.

I believe it should be possible to change the current behavior for case (1), because we control the code that decides where the tooltip appears for those. We could probably use system APIs to get the mouse pointer size and adapt the position for these tooltips.

However the screenshot seems to show an instance of case (2), and these tooltips should be generated based on each website's CSS definitions; in other words it's the websites themselves that decide the position where it should appear and we only make sure that we follow the CSS rules correctly to reproduce what the website owner intended. While I can understand how the described problem can be an issue, I'm not sure how we can help.

Also, while it may require using system APIs, I don't think that this issue is specific to Windows. Should consider moving this bug to Core :: Layout, where people may have clearer ideas about what we can or cannot do for case (2)?

If the cursor is set to a larger-than-normal size, I suspect the user will ordinarily want to zoom in, as well; if so, that handles case (2). (EDIT: although clearly not always, since this user didn't.)

Zooming in doesn't affect case (1), though, and for Windows there appears to be no documented way to get the cursor size. For reference, here is one undocumented option that doesn't involve reading the registry. (Only tested on Win10, but will probably work on Win7.)

DWORD GetWindowsCursorScaledSize() {
  DWORD val;
  const BOOL ret = ::SystemParametersInfo(0x2028, 0, &val, 0);
  return ret ? val : 32;
}

However, this is still likely to be a cross-platform issue, in that Mac and Linux will also need to have their cursor sizes queried and the tooltip position adjusted accordingly. (I don't envy whoever has to consider implementing this for Wayland.)

I think this is one level above Layout, and would be owned by DOM: Core? Bouncing to them for specifics and/or rebuttal.

Component: Widget: Win32 → DOM: Core & HTML

Thanks Ray for the additional information. Regarding case (2), zooming doesn't seem to solve the problem for me, or at least not for all websites: on Bugzilla, the tooltip shown when pointing the mouse to the author of a comment is still covered by my big cursor after zooming.

Morgan, do you think that case (1), adapting tooltips for the browser interface, should also be considered S2 for accessibility? Do you have an idea who we could ping about case (2)? Thanks.

Flags: needinfo?(mreschenberg)

on Bugzilla, the tooltip shown when pointing the mouse to the author of a comment is still covered by my big cursor after zooming.

That's a case (1) tooltip; it's generated by the title attribute. For a case (2) tooltip on Bugzilla, try hovering over the the "X (minutes/hours/days/...) ago" text just below the author, or over "Core" in the Product field at the top of the page.

(In reply to Ray Kraesig [:rkraesig] from comment #6)

That's a case (1) tooltip; it's generated by the title attribute. For a case (2) tooltip on Bugzilla, try hovering over the the "X (minutes/hours/days/...) ago" text just below the author, or over "Core" in the Product field at the top of the page.

I see, thanks for correcting me on this. That probably makes case (1) as important as case (2) then, since it can happen in websites? What do you think, Morgan?

(In reply to Yannis Juglaret from comment #7)

(In reply to Ray Kraesig [:rkraesig] from comment #6)

That's a case (1) tooltip; it's generated by the title attribute. For a case (2) tooltip on Bugzilla, try hovering over the the "X (minutes/hours/days/...) ago" text just below the author, or over "Core" in the Product field at the top of the page.

I see, thanks for correcting me on this. That probably makes case (1) as important as case (2) then, since it can happen in websites? What do you think, Morgan?

I think both of these are worth addressing -- maybe (1) more than (2) if there are ways for web authors to work around this bug via CSS (though I'm not sure there are). I'd say (1) is an access-s2 in cases where the tooltip reveals information that is not otherwise displayed on the page and is entirely eclipsed by the cursor, otherwise it's an access-s3. I can triage this as such.

re: who to contact about (2), I'm not sure but :emlio is always a good start :)

Flags: needinfo?(mreschenberg)
Flags: needinfo?(emilio)

The bugzilla case is not really fixable on Firefox's end, it's bugzilla who decides where to place the tooltip, and unless we expose the cursor size in some standard way this is an issue that you're going to find in various places and that sites can't really predict and fix.

Of course exposing system cursor size has extra fingerprinting surface etc, but maybe worth filing an issue in https://github.com/w3c/csswg-drafts/issues/new to request exposing the system cursor width/height?

Flags: needinfo?(emilio)
Duplicate of this bug: 1441049
Duplicate of this bug: 557754
Duplicate of this bug: 248718
Duplicate of this bug: 1476806

Thanks Morgan and Emilio for the updates! I will work on this problem in the beginning of January then. I will first file an issue for case (2) on the w3c github as Emilio suggested, then work on case (1) while waiting for progress on the w3c issue.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)

The bugzilla case is not really fixable on Firefox's end, it's bugzilla who decides where to place the tooltip, and unless we expose the cursor size in some standard way this is an issue that you're going to find in various places and that sites can't really predict and fix.

Of course exposing system cursor size has extra fingerprinting surface etc, but maybe worth filing an issue in https://github.com/w3c/csswg-drafts/issues/new to request exposing the system cursor width/height?

I have filed an issue, which I hope will start discussions on this topic: https://github.com/w3c/csswg-drafts/issues/8315

(In reply to Yannis Juglaret from comment #14)

Thanks Morgan and Emilio for the updates! I will work on this problem in the beginning of January then. I will first file an issue for case (2) on the w3c github as Emilio suggested, then work on case (1) while waiting for progress on the w3c issue.

Given that our user interface relies on CSS as well, it is actually simpler to implement both changes at once. I believe the only part in the user interface that would need to change once we have the CSS update, would be this line, from:

tooltip:not([position]) {
  margin-top: 21px;
}

To something like (first proposal):

tooltip:not([position]) {
  margin-top: calc(5px + 1sch);
}

Or like (second proposal):

tooltip:not([position]) {
  margin-top: calc(5px + anchor(cursor height, 16px));
}

I'm thus currently working on implementing the simplest of the two proposals (the first) to get familiar with the code base, then depending on what proposal gets accepted I may have to adapt my changes.

I've started working on the Windows-specific part of the change now.

(In reply to Ray Kraesig [:rkraesig] from comment #4)

[...] for Windows there appears to be no documented way to get the cursor size. For reference, here is one undocumented option that doesn't involve reading the registry. (Only tested on Win10, but will probably work on Win7.)

DWORD GetWindowsCursorScaledSize() {
  DWORD val;
  const BOOL ret = ::SystemParametersInfo(0x2028, 0, &val, 0);
  return ret ? val : 32;
}

This helps (thanks!) but it's not enough; it gives an idea of the scale that is applied to the bitmap at least, but I'm afraid we must also read the bitmap that is used and look for transparent columns and rows. See e.g. below the arrow pointer's opacity values for the Windows 11 32x32 arrow cursor, and its 19 columns of zeros on the right side, 13 rows of zeros at the bottom!

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 93 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff fe 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff ff fe 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff ff ff fe 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff ff ff ff fe 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff ff ff ff ff fe 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff ff ff ff ff ff fe 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff ff ff ff ff ff ff fe 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff ff ff ff ff ff ff ff fe 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff ff ff ff ff ff ff ff ff fe 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff ff ff ff ff ff ff ff ff ff ff 8f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff ff ff ff ff ff ff 87 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff ff ff e7 ff ff ff f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff ff 10 00 f7 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ff 10 00 00 00 ff ff ff ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 fb ff ff 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

If we ignore the transparent parts of the cursor and just just take the "official" size of the bitmap, then the look&feel is really bad, as the tooltip just shows very far away from the cursor. For the part that only applies to Firefox, though, I guess for the moment we can simply scale the previously hardcoded 21 px / 32.

But the transparent parts will make it harder to have something as simple as I expected for the CSS standard (in fact, somebody already mentioned this on the CSSWG issue, but I was somehow hoping that we wouldn't encounter it for "official" system cursors). At least that's something to take into account.

Apologies; "cursor size" should of course have been "cursor scale". (I'll be happy to learn that just reading the cursor bits suffices; but I fear that for the case where a custom cursor doesn't provide the particular size Windows wants, ::GetIconInfo will only give the base bitmap that Windows has rescaled, and we'll need to do some sort of horrible synthesis.)


EDIT: Two users popped up within a day to present themselves as counterexamples to my reasoning below, which suffices to relieve me of my belief in it. Objection withdrawn! (The comment remains in place for historical reference.)

That said, I'm quite surprised that this would be considered worth even exposing additional fingerprinting surface, let alone adding new features to CSS (with subsequent churn in most if not all CSS-processing tools). While providing some sort of internal implementation to handle case (1) is necessary, I would still have expected that the user zooming in to work around case (2) suffices — mostly on the grounds that users who increase their default cursor size will normally also increase their default page zoom, and so will never notice that a workaround was needed.

Or, perhaps phrased differently: even if they can (and possibly even should) share implementation details, I think case (1) and case (2) are ultimately different bugs that should be triaged differently. I agree that case (1) is [access-s2], but I don't see that case (2) is more than [access-s3].

Just on this point:
(In reply to Ray Kraesig [:rkraesig] from comment #19)

on the grounds that users who increase their default cursor size will normally also increase their default page zoom, and so will never notice that a workaround was needed.

I am a user who increases the cursor size but not the default page zoom -- that's why I originally filed one of the duplicates. We exist!
(But I understand about the fingerprinting issue, and that it needs proper assessment.)

I use user css to specify font sizes.

If I use about:preferences alone, I can set a minimum font size, but not a maximum.

If I use text zoom or full-page zoom alone, different pages will require different zoom levels, and increasing the smallest text to a comfortable size will often increase the largest text to an impractical or unreadable size. In the past, I'd also encounter trouble scrolling pages and selecting text.

(In reply to Ray Kraesig [:rkraesig] from comment #19)

I'll be happy to learn that just reading the cursor bits suffices; but I fear that for the case where a custom cursor doesn't provide the particular size Windows wants, ::GetIconInfo will only give the base bitmap that Windows has rescaled, and we'll need to do some sort of horrible synthesis.

Indeed we need to combine both pieces of information; the 32x32 bitmap I shared previously was obtained with GetIconInfo (and my cursor was large at that point, so my real cursor was 64x64 <-- this remark was misleading, sorry).

That said, I'm quite surprised that this would be considered worth even exposing additional fingerprinting surface, let alone adding new features to CSS (with subsequent churn in most if not all CSS-processing tools). While providing some sort of internal implementation to handle case (1) is necessary, I would still have expected that the user zooming in to work around case (2) suffices — mostly on the grounds that users who increase their default cursor size will normally also increase their default page zoom, and so will never notice that a workaround was needed.

Or, perhaps phrased differently: even if they can (and possibly even should) share implementation details, I think case (1) and case (2) are ultimately different bugs that should be triaged differently. I agree that case (1) is [access-s2], but I don't see that case (2) is more than [access-s3].

It's still up to us to decide how much fingerprinting surface we want to add though. Just an example, but we could decide to have the new CSS feature always return fixed values that work well for most people by default; then if we detect a non-standard cursor size we could ask the user if they would rather expose this information to websites. Or, we could add a pref to expose up-rounded values that are close to the real cursor size but not exactly it and activate it by default. Or, we could also have a pref that lets users manually specify what value they want to have returned to websites. Or a combination of all these solutions.

Thank you Gerald and MarjaE for your patience and for continuing to actively monitor this discussion 5 years after filing your respective bugs. Whether [access-s2] or [access-s3], I hope we can find a way to address both problems, and I believe this requires at least allowing users to willingly expose some additional information to websites about there cursor size -- which in turn requires changing the web standards.

See Also: → 1814399
Assignee: nobody → yjuglaret

(In reply to Gerald Squelart (he/him) from comment #20)

I am a user who increases the cursor size but not the default page zoom [...]

(In reply to MarjaE from comment #21)

I use user css to specify font sizes [...]

Well then. Please consider me corrected on this matter!

I believe "CSS Parsing and Computation" is a better component than "DOM: Core & HTML" According to the discussions above, regarding the potential css spec issue or where the changes in the WIP indicate.

Component: DOM: Core & HTML → CSS Parsing and Computation

I think a reasonable path forward for now would be to expose a env(safe-cursor-size) as a chrome-only environment variable and use it for our native tooltips. Yannis, do you still have cycles to work on this? Happy to help out with the details.

Flags: needinfo?(yjuglaret)

Hi [:emilio],

Yes I still plan to work on this, thanks for the ping. For the chrome part, I had an ongoing patch in bug 1814399; it still needs polishing (e.g. caching?) but it works as a PoC. I did not use an environment variable because I think that makes it impossible to adapt to changes in the cursor? Am I wrong on this?

As explained in that bug I think we would need to switch the offset if the cursor changes from Arrow (used e.g. for tooltips when hovering tabs) to (used e.g. when hovering text that has a title attribute), otherwise using the same offset for both feels weirder and weirder as the cursor size grows. I'll try to show this with images. (Also the cursor size could change dynamically.) What do you think?

Flags: needinfo?(yjuglaret)

So changing it dynamically depending on the cursor is probably not great because you can get into circularities (e.g., changing cursor based on the offset or what not).

I don't think this qualifies as S2.

Severity: S2 → S3
Priority: P2 → P3
Accessibility Severity: --- → s2
Whiteboard: [access-s2]

Very painful because there is no workaround. If the tooltip is occluded, you generally can't move the mouse and read fast enough before it goes away. It appears to be a problem in Chromium web content as well, and Edge UI. But not a problem in Windows OS and some apps because they choose to show their tooltips above the cursor (to deal with this perhaps)

I think we should start off with this. Other platforms can implement
this too, but exposing this to content seems like quite the rabbit hole.

Attachment #9314828 - Attachment is obsolete: true
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/21973e46f7ea
Make Windows tooltip margin depend on cursor size. r=yjuglaret,win-reviewers,desktop-theme-reviewers,dao

Backed out for causing mochitest failures in test_tooltip.xhtml

  • Backout link
  • Push with failures
  • Failure Log
  • Failure line: TEST-UNEXPECTED-FAIL | toolkit/content/tests/chrome/test_tooltip.xhtml | hover tooltip attribute top position of tooltip - got 37, expected 16
    TEST-UNEXPECTED-FAIL | toolkit/content/tests/chrome/test_tooltip.xhtml | hover tooltip after size increased top position of tooltip - got 35, expected 14
    TEST-UNEXPECTED-FAIL | toolkit/content/tests/chrome/test_tooltip.xhtml | hover tooltip after size decreased top position of tooltip - got 37, expected 16
Flags: needinfo?(emilio)
Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/79f80b3cf047
Make Windows tooltip margin depend on cursor size. r=yjuglaret,win-reviewers,desktop-theme-reviewers,dao
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 126 Branch
See Also: → 1888888
Component: CSS Parsing and Computation → Widget: Win32
Assignee: yjuglaret → emilio
Flags: qe-verify+

I've replicated scenario (1), which involves tooltips displayed as part of the browser interface when hovering over the name of a tab, using Nightly 125.0a1 on Windows10 x64. Verified as fixed in the latest Firefox 126.0b3 under the same configuration, as the issue no longer occurs.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: