Open Bug 1440640 Opened 7 years ago Updated 2 years ago

stylo: The search suggestions hint is not vertically centred with Dark/Light themes on Linux after dynamically switching theme

Categories

(Core :: CSS Parsing and Computation, defect, P3)

60 Branch
Unspecified
Linux
defect

Tracking

()

Tracking Status
firefox-esr52 --- unaffected
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- affected

People

(Reporter: roxana.leitan, Unassigned)

References

Details

Attachments

(1 file)

Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID:20180223001838 [Affected versions]: Nightly 60.0a1 [Affected platforms]: Ubuntu 16.04 X64 [Steps to reproduce]: 1.Launch Nightly 60.0a1 with a new profile 2.Focus the Awesome bar by hitting the Ctrl+L keys 3.Enable Dark theme from about:addons -> theme section 4.Open a new tab 5.Focus the Awesome bar by hitting the Ctrl+L keys [Expected result]: The search suggestions hint should be correctly displayed. [Actual result]: The search suggestions hint is not vertically centred. It appears in the upper margin of the box [Note]: The issue is reproducible also with Light theme following the same STR. The issue is not reproducible if the Awesome bar is not opened with the browser normal theme first.
I cannot reproduce this, any chance of seeing an screenshot of the problem? To be clear, the "search suggestions hint" is the small arrow pointing downwards, right? Also, I'm assuming that this is not reproducible with layout.css.chrome.enabled=false, per the bug you've blocked, but worth confirming it.
Flags: needinfo?(roxana.leitan)
Attached video video-1519395567.mp4 (deleted) —
I cannot reproduce with layout.css.chrome.enabled=false.
Flags: needinfo?(roxana.leitan)
FWIW: I *was* able to reproduce this on my first try (in Nightly with a fresh profile), but then I wasn't able to reproduce again in more fresh profiles. So there seems to be a bit of randomness/raciness involved here, or maybe some subtle piece I'm not noticing that avoids (or triggers) the problem.
OK, I can reproduce reliably (I think -- twice in a row) by *precisely* following this expanded version of the STR from comment 0 (the "click a blank spot" parts seem to be important) 1.Launch Nightly 60.0a1 with a new profile 2.Focus the Awesome bar by hitting the Ctrl+L keys 3.After the yellow "Tip" appears, click a blank spot on the page (to unfocus the awesomebar) 4.Press Alt-T, and then A (to open tools menu & pick "add-ons") 5.Click "Themes", and then "Enable" to the right of Dark 6.Open a new tab 7.Click a blank spot on the page (to unfocus the awesomebar) 8.Focus the Awesome bar by hitting the Ctrl+L keys
Priority: -- → P1
Summary: The search suggestions hint is not vertically centred with Dark/Light themes on Linux → stylo: The search suggestions hint is not vertically centred with Dark/Light themes on Linux
Summary: stylo: The search suggestions hint is not vertically centred with Dark/Light themes on Linux → stylo: The search suggestions hint is not vertically centred with Dark/Light themes on Linux after dynamically switching theme
Given the convoluted STR I think this doesn't matter too much, fwiw. Anyway, I could reproduce it, but I'm having a pretty hard time to diagnose it, since obviously trying to somehow inspect it using the content toolbox unfocuses the awesomebar and hides it :(
Changing priority from P1 to P3 because this bug doesn't need to block shipping Stylo-chrome. It's a visual issue that only affects Linux using non-default themes.
(In reply to Emilio Cobos Álvarez [:emilio] from comment #5) > Anyway, I could reproduce it, but I'm having a pretty hard time to diagnose > it, since obviously trying to somehow inspect it using the content toolbox > unfocuses the awesomebar and hides it :( Perhaps Marco has some debugging tips to share?
Flags: needinfo?(mak77)
from the Browser console you can let listener = event => event.preventDefault(); gURLBar.popup.addEventListener("popuphiding", listener); removeEventListener when done
Flags: needinfo?(mak77)
Downgrading priority from P1 to P2 because this bug doesn't block shipping Stylo-chrome. Emilio thinks his fix for bug 1441022 may also fix this bug.
Priority: P1 → P3
Roxana, once the next nightly is released with bug 1441022, can you re-test this?
Flags: needinfo?(roxana.leitan)
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID:20180311220116 The issue is reproducible on the latest Nightly (2018-03-11).
Flags: needinfo?(roxana.leitan)
thanks Roxana. Maire, can you make a call as to whether you want anybody to spend cycles chasing this down? Per comment 6 it feels like a pretty low priority. There's a small chance that there's an underlying important issue here that could crop up elsewhere in the browser UI, but there's also a good chance that the issue is a weird interaction between various bits we don't care much about. Given that stylo-chrome is enabled for beta, it feels unlikely that we'd go for long without any show-stopping UI bugs being reported. As such I'd lean towards not having emilio investigate, but leave the decision up to you.
Flags: needinfo?(mreavy)
Thanks, Bobby. I agree this is a P3 bug based on what we know, and it doesn't make sense to invest further cycles at this point.
Flags: needinfo?(mreavy)
Per comment 13 this doesn't block stylo-chrome.
No longer blocks: stylo-chrome
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: