Closed Bug 1549787 Opened 6 years ago Closed 5 years ago

Some URLs in autocomplete items are sometimes unnecessarily getting a fading effect, if Quantumbar is on

Categories

(Firefox :: Address Bar, defect, P2)

defect
Points:
5

Tracking

()

VERIFIED FIXED
Firefox 69
Iteration:
69.2 - May 27 - Jun 9
Tracking Status
firefox-esr60 --- unaffected
firefox67 --- unaffected
firefox68 --- fixed
firefox69 --- verified

People

(Reporter: itiel_yn8, Assigned: dao)

References

(Regression)

Details

(Keywords: regression)

Attachments

(6 files)

Attached image Screenshot 1 (deleted) —

Windows 10, latest Nightly, browser.urlbar.quantumbar = true

I'm pretty sure this is something new (from the past week or so).

I'm unable to reproduce this on a new profile, but am able to reproduce consistently on my main profile.
Sometimes some URLs for autocomplete items will get the fading effect even when not unnecessary.
For this to reproduce I must type slowly in the URL bar (i.e. wait for results to appear after each key stroke)

See attached.

Attached image Screenshot 2 (deleted) —
Attached image Screenshot 3 (deleted) —

I cannot reproduce this on my Win10... do you have any userchrome.css or chrome/ modifications in your profile?
Does adding/removing the search bar make any difference?

Flags: needinfo?(itiel_yn8)

(In reply to Marco Bonardo [::mak] from comment #3)

do you have any userchrome.css or chrome/ modifications in your profile?

No userchrome.css or similar. What kind of modifications are you looking for? Just the normal stuff you can do from the Customize page.

Does adding/removing the search bar make any difference?

No :(

This reproduces here for both RTL and LTR btw.

Flags: needinfo?(itiel_yn8)

fwiw this reproduces also in safe mode.

There must be some difference between your profile and the clean profile where you say this doesn't happen... Could you try copying places.sqlite from your profile to the clean one and try the same identical search? Could you please try to customize the new profile toolbars identical to the default profile and see if you can cause this bug in that profile?

I'm trying to identify a cause that would allow me to reproduce.

Flags: needinfo?(itiel_yn8)

(In reply to Marco Bonardo [::mak] from comment #6)

There must be some difference between your profile and the clean profile where you say this doesn't happen... Could you try copying places.sqlite from your profile to the clean one and try the same identical search? Could you please try to customize the new profile toolbars identical to the default profile and see if you can cause this bug in that profile?

All done (plus unticked the "Show search suggestions ahead of browsing history in address bar results" preference to match my main profile), still this works in the new profile.
What files should be related to the URL bar functionality that I can copy from the old profile over to the new profile and re-test?
I've already tried copying prefs.js (resulted in a somewhat corrupted profile) and favicons.sqlite (not really related but I'm out of ideas).

Flags: needinfo?(itiel_yn8)

maybe try attaching here a log from about:support, I may get ideas. In general this kind of things may be related to chrome style changes, or graphics/layout settings. It is strange anyway, because it looks like we are miscalculating the size of the flexbox, that would be a layout bug...

Points: --- → 5
Priority: -- → P2
Attached file about:support log (deleted) —

The only relevant thing I didn't try yet, is that this is an "he" nightly build, though I don't know how that should make a difference compared to the new profile... did you change some text direction of font related prefs?
I guess I should try this localized build.

(In reply to Marco Bonardo [::mak] from comment #10)

The only relevant thing I didn't try yet, is that this is an "he" nightly build, though I don't know how that should make a difference compared to the new profile...

Both profiles (the one being my main profile and the second is the new one where I can't reproduce the issue) are Hebrew build, using the same installation of Nightly. So I can't see it being the cause here.

did you change some text direction of font related prefs?

None that I can remember.

I tried the he build, and still cannot reproduce, I am running out of ideas :(

Do you have any prefs not at default value under layout.*?
what's value for layout.css.devPixelsPerPx and layout.css.dpi?

layout.spellcheckDefault = 0

layout.css.devPixelsPerPx = -1.0
layout.css.dpi = ‎-1

Windows DPI is set to 150% btw.

Depends on: 1550036

Please, let us know if the next nightly including bug 1550036 solves your problem.

Flags: needinfo?(itiel_yn8)
Iteration: --- → 69.1 - May 13 - 26
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED

Not sure if the fix for bug 1550036 is included in the current Nightly (about:build config leads me to https://hg.mozilla.org/mozilla-central/rev/34a824c75b7b5618a06ba8987c418d6363da5038), but if it is- I'm still seeing the issue here.

Flags: needinfo?(itiel_yn8)

(In reply to Itiel from comment #15)

Not sure if the fix for bug 1550036 is included in the current Nightly (about:build config leads me to https://hg.mozilla.org/mozilla-central/rev/34a824c75b7b5618a06ba8987c418d6363da5038),

The fix is included there.

Since we can't reproduce this, could you help us find the regression range?

Flags: needinfo?(itiel_yn8)

(In reply to Dão Gottwald [::dao] from comment #16)

(In reply to Itiel from comment #15)

Not sure if the fix for bug 1550036 is included in the current Nightly (about:build config leads me to https://hg.mozilla.org/mozilla-central/rev/34a824c75b7b5618a06ba8987c418d6363da5038),

The fix is included there.

Since we can't reproduce this, could you help us find the regression range?

I tried at first (by reusing my main profile to bisect with Mozregression) but the profile kept on becoming corrupted.
Anyway, I've tried bisecting again but this time a bit farther back in time and I think I got it right:

2019-05-09T19:57:04: DEBUG : Starting merge handling...
2019-05-09T19:57:04: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=29c131c2fd402f750064800c41037f534cea5cfd&full=1
2019-05-09T19:57:06: DEBUG : Found commit message:
Bug 1545394 - Keep stale rows in the view while receiving new results. r=mak

Differential Revision: https://phabricator.services.mozilla.com/D28049

2019-05-09T19:57:06: DEBUG : Did not find a branch, checking all integration branches
2019-05-09T19:57:06: INFO : The bisection is done.

Flags: needinfo?(itiel_yn8)

Thanks!

Regressed by: 1545394

(In reply to Marco Bonardo [::mak] from comment #6)
All done (plus unticked the "Show search suggestions ahead of browsing history in address bar results" preference to match my main profile), still this works in the new profile.

How about the reverse? Can you reproduce this in your main profile if you reset that pref?

Flags: needinfo?(itiel_yn8)

(In reply to Dão Gottwald [::dao] from comment #19)

(In reply to Marco Bonardo [::mak] from comment #6)
All done (plus unticked the "Show search suggestions ahead of browsing history in address bar results" preference to match my main profile), still this works in the new profile.

How about the reverse? Can you reproduce this in your main profile if you reset that pref?

Yes.

Flags: needinfo?(itiel_yn8)
Attached image Screenshot 4 (deleted) —

I've finally seen this happen with my profile, with search suggestions disabled. It's quite intermittent and I can't easily reproduce it by just doing the same query again.

(In reply to Dão Gottwald [::dao] from comment #22)

I've finally seen this happen with my profile, with search suggestions disabled. It's quite intermittent and I can't easily reproduce it by just doing the same query again.

This happens to me sometimes as well (though with search suggestions on), but I can bump the chances to see this by opening many tabs (with different urls in each), in a new tab typing "%" followed by any character and hitting Ctrl (to see the urls). In one of the next tries the issue reproduces.

(In reply to Itiel from comment #23)

(In reply to Dão Gottwald [::dao] from comment #22)

I've finally seen this happen with my profile, with search suggestions disabled. It's quite intermittent and I can't easily reproduce it by just doing the same query again.

This happens to me sometimes as well (though with search suggestions on), but I can bump the chances to see this by opening many tabs (with different urls in each), in a new tab typing "%" followed by any character and hitting Ctrl (to see the urls). In one of the next tries the issue reproduces.

That doesn't seem to do the trick over here.

Cristian, could you help us trying to reproduce this reliably?

Flags: needinfo?(cristian.comorasu)
Keywords: steps-wanted

(In reply to Dão Gottwald [::dao] from comment #24)

(In reply to Itiel from comment #23)

(In reply to Dão Gottwald [::dao] from comment #22)

I've finally seen this happen with my profile, with search suggestions disabled. It's quite intermittent and I can't easily reproduce it by just doing the same query again.

This happens to me sometimes as well (though with search suggestions on), but I can bump the chances to see this by opening many tabs (with different urls in each), in a new tab typing "%" followed by any character and hitting Ctrl (to see the urls). In one of the next tries the issue reproduces.

That doesn't seem to do the trick over here.

If needed, I'm willing to upload my profile for you to test.

(In reply to Itiel from comment #26)

If needed, I'm willing to upload my profile for you to test.

Feel free to send it to my email address (without +bmo) and I'll give it a try, but I suspect we have a race condition here and it not only depends on your profile but also on your system.

Iteration: 69.1 - May 13 - 26 → 69.2 - May 27 - Jun 9

(In reply to Dão Gottwald [::dao] from comment #27)

(In reply to Itiel from comment #26)

If needed, I'm willing to upload my profile for you to test.

Feel free to send it to my email address (without +bmo) and I'll give it a try, but I suspect we have a race condition here and it not only depends on your profile but also on your system.

Email sent.

(In reply to Itiel from comment #28)

(In reply to Dão Gottwald [::dao] from comment #27)

(In reply to Itiel from comment #26)

If needed, I'm willing to upload my profile for you to test.

Feel free to send it to my email address (without +bmo) and I'll give it a try, but I suspect we have a race condition here and it not only depends on your profile but also on your system.

Email sent.

Got it, thanks! Unfortunately, I still can't seem to reproduce this with your steps from comment 23. Tried different window sizes too. This is on Ubuntu, I can try Windows 10 next.

(In reply to Dão Gottwald [::dao] from comment #29)

Got it, thanks! Unfortunately, I still can't seem to reproduce this with your steps from comment 23. Tried different window sizes too. This is on Ubuntu, I can try Windows 10 next.

Looking back at comment 23, I guess I omitted a few steps:

  1. Start Nightly using my profile, with all the 370~ tabs, in full screen
  2. Open a new tab
  3. Type "%" followed by any character
  4. Hit Ctrl and see that one of the entries URL are unnecessarily faded out
  5. If none of them are (happens to me sometimes), repeat step 3 with a different character
  6. Usually when you can reproduce step 4, you can then clear the url bar text and start typing "9gag" or "google" and then you'll see the autocomplete for some 9gag.com entries and for translate.google.co.il being unnecessarily faded out.

If you're still unable to reproduce, can I do something over here to debug this for you?

Alright, I can reproduce now with your profile and with those steps on Windows 10.

Flags: needinfo?(cristian.comorasu)
Keywords: steps-wanted

I have a patch that seems to fix this. Itiel, could you please check if you can reproduce the bug with this build? https://queue.taskcluster.net/v1/task/Dl099TIEQYGrIppHVbkPYQ/runs/0/artifacts/public/build/target.zip

Flags: needinfo?(itiel_yn8)

(In reply to Dão Gottwald [::dao] from comment #32)

I have a patch that seems to fix this. Itiel, could you please check if you can reproduce the bug with this build? https://queue.taskcluster.net/v1/task/Dl099TIEQYGrIppHVbkPYQ/runs/0/artifacts/public/build/target.zip

Not reproducing on this build running with the same profile, also in RTL :)

Flags: needinfo?(itiel_yn8)
Attachment #9068354 - Attachment description: Bug 1549787 - WIP → Bug 1549787 - Hide rows and row elements using visibility:collapse instead of display:none since the latter can confuse the overflow state of title/url/action elements.
Attachment #9068354 - Attachment description: Bug 1549787 - Hide rows and row elements using visibility:collapse instead of display:none since the latter can confuse the overflow state of title/url/action elements. → Bug 1549787 - Hide row elements using visibility:collapse instead of display:none since the latter can confuse the overflow state of title and url elements.
Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3b055a26c9b6 Hide row elements using visibility:collapse instead of display:none since the latter can confuse the overflow state of title and url elements. r=mak
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 69

Fixed now on latest Nightly.

Status: RESOLVED → VERIFIED

Comment on attachment 9068354 [details]
Bug 1549787 - Hide row elements using visibility:collapse instead of display:none since the latter can confuse the overflow state of title and url elements.

Beta/Release Uplift Approval Request

  • User impact if declined: see comment 0
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): reasonably straightforward patch, contains some refactoring making this code easier to maintain
  • String changes made/needed:
Attachment #9068354 - Flags: approval-mozilla-beta?

Comment on attachment 9068354 [details]
Bug 1549787 - Hide row elements using visibility:collapse instead of display:none since the latter can confuse the overflow state of title and url elements.

quantum bar fix for 68.0b8

Attachment #9068354 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: