1611916 - Generic UI tooltip style not updated until DOM is inspected in browser toolbox

Status: UNCONFIRMED

(Core :: CSS Parsing and Computation, enhancement)

Description

[Shane Hughes [:aminomancer]]

Attachment: tooltipStyling.uc.js

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

Steps to reproduce:

• Apply some style to tooltips, in userchrome.css or preferably in a userscript that loads the rules as an agent sheet. Example is attached.
• I don't know if this is important, but I have multiprocess browser toolbox enabled.
• Make sure the browser toolbox is closed, then restart firefox.
• Hover over a UI element with "tooltiptext" attribute, like the history button or all tabs button.

Actual results:

The generic/default tooltip that appears does not obey the tooltip style anymore. It used to. I can't remember when exactly and I don't have much time to do a regression, but around v72. After a subsequent update, this problem went away for a few days, then came back.

Anyway, now that you see the tooltip isn't styled (whereas unique tooltips do obey your style, for example hover over the back/forward buttons), hit ctrl+shift+alt+i to open the browser toolbox. Go to the inspector tab. Now hover one of the buttons with a generic tooltip again. Suddenly it is styled, and will stay that way until you quit FF, even if you close the toolbox.

I can't guess why this is the case but I guess I'm not surprised there would be issues here. Like the non-generic tooltips have IDs. The generic tooltip is visible in the DOM, for me it's the last child of #main-window, in browser.xhtml and in dummy.xhtml. But if you run document.querySelectorAll('tooltip') you'll see every tooltip except the generic tooltip, even if you run it while the tooltip is visible. It's obviously not a normal element but I don't see why its selectability should change after the browser toolbox is opened.

Expected results:

I guess this behavior isn't surprising, but it shouldn't be unavoidable, since these rules worked fine until a couple months ago. The agent sheet should style the tooltips immediately and shouldn't require the user to open the dev tools. I know it's a minor issue that only affects people who use custom css and scripts and care about 'dark mode' and so on, so I'm marking it as a request for enhancement, but I do think this could be a defect since it only appeared recently, then disappeared in another update before ultimately reemerging.

But since I'm marking it as a request, it would be cool if the tooltip implementation was overhauled such that the browser didn't use generic OS styles at all. The shadow is pretty ugly and I'd also like to be able to change the opacity. I know customizability isn't a big deal, but firefox is supposed to support dark mode. The components that remain bright must really be an eyesore for casual users who enable dark mode. I have spent a lot of my time styling UI elements like that, for example the context menus, and I'd be happy to contribute my stylesheets to mozilla if someone is willing to walk me through the process of submitting them.

But there's not much anyone could do about the tooltips since apparently you have to open the browser toolbox every time FF starts up, and most users don't even know what that is. If this were fixed and the tooltips were overhauled in the same way checkboxes in the about:preferences page were modernized, a lot of users would appreciate it even if they don't care enough to post a bug report about it. I think generic tooltips should be treated the way modal dialogs are, or even the urlbar popup. I can make the urlbar results perfectly match windows' acrylic UI effect by setting them to 60% opacity and adding a noise background image and backdrop-filter. This would look nice on tooltips and modal dialogs and I'd love to help design that, but for reasons I don't understand it's like these elements are not part of the main window or something. But at least a softer shadow without any offset, the ability to make them less opaque, and making the color & background-color tied to the firefox theme so they don't defeat the purpose of dark mode.

Comment 1

[Daniel Bodea [:danibodea]]

Considering the detailed way this enhancement was described and the fact that it is a bit too technical for me to try and reproduce, I will set this bug's component as (Core) CSS Parsing and Computation and hope it will be addressed further.

If the chosen component is incorrect, please set a more appropriate one rather than setting it back to Untriaged or to General.
I would like to properly confirm and regress it if more detailed (or simple to use) steps to reproduce are being provided.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Is there any chance you could run mozregression to see when this broke? I think what happens is that the default tooltip didn't use to be "Native Anonymous Content" and now it is.

I think some of our style system optimizations to restyle as little as possible may be assuming that NAC doesn't change dynamically. Should be fixable.

To verify this, does adding a global selector to that stylesheet fix it? (On my phone atm so can't check myself, will do later).

Comment 3

[Shane Hughes [:aminomancer]]

If I do * {tooltip rules blah blah} it styles everything except the generic tooltips. So apparently not

Comment 4

[Shane Hughes [:aminomancer]]

I'm not sure how to do a regression for something like this btw, since loading the stylesheet with a script requires autoconfig files

Comment 5

[Emilio Cobos Álvarez (:emilio)]

You can pass --profile <path>, as far as I can tell.

Comment 6

[Shane Hughes [:aminomancer]]

autoconfig files go in the install folder, not the profile. I tried a regression anyway, and as I expected the javascript loader did not work, but I put the tooltip styling in a userChrome.css file at least. But styling the generic tooltips with userChrome.css has never worked afaik. In the time I've used firefox I've never been able to do it with a usersheet. The difference is that in the past, I was at least able to style these tooltips with an agent or author sheet loaded via javascript. Since 72 or something, agent sheets do work on these tooltips but only after loading the inspector in the UI-level browser toolbox. So I didn't expect the regression to yield anything since I could only load the rules in a usersheet. And I tested 66 through 72 and none of them were good. My css rules worked on all the unique tooltips in every build