1585970 - [Intermittent] The magnifying glass icon is not displayed in the search bar after navigating to about:logins from an entry point

Status: RESOLVED WORKSFORME

(Firefox :: about:logins, defect, P5)

Description

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Attachment: Recording #42.mp4

[Notes]:

• The issue is intermittent and is not reproducible every time. If it's not reproducible after the first attempt you need to restart the browser and try again.
• The issue is reproducible on white and also in dark mode.
• I have also managed to reproduce the issue by navigating to the about:logins page from autofill, context menu, "about:protections" page and Hamburger menu.
• The icon is redisplayed after a browser restart.

[Affected Versions]:

• Nightly 71.0a1
• Beta 70.0b11

[Affected Platforms]

• All Windows
• All Mac
• All Linux

[Steps to reproduce]:

1. Open the latest Nightly/Beta browser.
2. Click the "Firefox Account" button from the browser toolbar.
3. Click the "Logins and Passwords" option from the displayed menu.
4. Observe the search bar.

[Expected results]:

• The magnifying glass icon is correctly displayed.

[Actual results]:

• The magnifying glass icon is not displayed.

[Additional Notes]:

• Attached a screen recording with the issue.

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

I'm unable to reproduce it on Windows after multiple attempts. Are there any errors in the web console when this happens?

Comment 2

[Simona Rosu [:srosu], Ecosystem QA]

I have managed to reproduce this issue a couple of times but when comparing the Browser Console output when the issue is reproduced with the output when it is not, I have obtained the same errors and warnings.

I Have also tried to investigate further if there are any differences in the Network section from the Web Console, but sadly the only resource that is loaded is the profile picture.

I’ll try to reproduce it once more, probably tomorrow and provide a screenshot of the Browser Console for further investigation.
If you have any tips on how I could better investigate this, please let me know.

Comment 3

[Simona Rosu [:srosu], Ecosystem QA]

I have continued to verify this issue but I haven't been able to reproduce it more than once. Testing was performed on Nightly 71.0a1 (Build ID: 20191013213650) and on Firefox Beta 70.0b14 (Build ID: 20191010142853).

It might have been fixed along the way with other changes that landed, or the steps might have changed, making the bug harder to reproduce.
As the issue was intermittent before I have verified it on multiple profiles: 10 profiles on Windows 10 x64, 15 profiles on Mac 10.14 and 5 profiles on Ubuntu 16 x64.

Please let me know if you think I should spend more time to investigate this.

Comment 4

[David Durst [:ddurst]]

I can't reproduce this. I suggest we table it unless we get STR that are consistent or user complaints.

Comment 5

[Matthew N. [:MattN]]

Mass removing [skyline] and [passwords:management] from about:logins bugs which are no longer useful.

Comment 6

[Itiel]

I've also seen this a few months ago, but not anymore.
Cosmin/Simona, can you still reproduce this?

Comment 7

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Attachment: Screen Shot 2020-04-01 at 18.22.06.png

Yes, I have seen this behavior today on a new Nightly 76.0a1 build after syncing logins. Unfortunately, I don't have any specific steps that are 100% reproducible. I have encountered this issue on macOS 10.14.6 using the dark theme. I have added a screenshot with it.

Comment 8

[Itiel]

Interestingly, I remember that when this happened, unticking the background-image property for the .filter[type="text"] rule and selecting it back again made the issue go away (for that session, of course).

This makes me think this is not an about:logins issue...

Gijs, does that sound to you like a graphics issue?

Comment 9

[:Gijs (he/him)]

(In reply to Itiel from comment #8)

Interestingly, I remember that when this happened, unticking the background-image property for the .filter[type="text"] rule and selecting it back again made the issue go away (for that session, of course).

This makes me think this is not an about:logins issue...

Gijs, does that sound to you like a graphics issue?

I don't know. I agree it doesn't sound like an about:logins issue, and I know we've had a similar issue with the search (like search engine, not like search in page) box on the new tab page in the past - though I can't find the bug right now... :-(

But even if it's a graphics issue, without STR or an rr / pernosco recording it'll be hard to do much here.

Comment 10

[Itiel]

I can reproduce this now on (almost) every new profile I create.
So the STR for me (on this particular machine at least) is:

1. Create a new profile
2. Launch it
3. Click the menu > Logins & Passwords

That's it. I realize this may still not be enough, but this is as minimalistic as I can...
Out of 10 new profiles I created, on 8 of them I managed to reproduce it using the above STR without doing anything else. After restarting Nightly in the other 2 cases, the issue was again reproduced.

Comment 11

[Matthew N. [:MattN]]

I just saw this on my Windows VM too with Firefox 76 Beta. Can you attach your about:support and we can compare?

Comment 12

[Matthew N. [:MattN]]

Attachment: Firefox 76 Beta on Windows about:support

Comment 13

[Itiel]

Attachment: Nightly 2020.04.16 on Windows 10

This is from the fresh profile.

Comment 14

[:Gijs (he/him)]

Ni for comment #13 to compare about:support data to work out what might trip this

Comment 15

[Itiel]

Huh, I managed to reproduce this also on the new tab page, where the search engine icon was missing...

Comment 16

[:Gijs (he/him)]

Itiel, are you still seeing this?

Comment 17

[Itiel]

(In reply to :Gijs (he/him) from comment #16)

Itiel, are you still seeing this?

Yup.

Comment 18

[:Gijs (he/him)]

(In reply to Itiel from comment #17)

(In reply to :Gijs (he/him) from comment #16)

Itiel, are you still seeing this?

Yup.

When this reproduces, does the network request in the network monitor appear complete?

If so, I'm guessing there's some kind of imglib or graphics issue, and we may be able to determine what's going on using MOZ_LOG-based logging.

Comment 19

[Itiel]

(In reply to :Gijs (he/him) from comment #18)

When this reproduces, does the network request in the network monitor appear complete?

I'm afraid I'm not sure what the network monitor has to do with any of this :-)
In any case, I've tried loading (and reloading) the about:logins page multiple times and no network requests are logged in the network monitor (both in the normal devtools and in the toolbox).

and we may be able to determine what's going on using MOZ_LOG-based logging.

I'd be glad to try that, but I'd likely need hand-holding as I'm not familiar with the process.
Are the steps here what I'm looking for? (aside from the parameters)
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Comment 20

[:Gijs (he/him)]

(In reply to Itiel from comment #19)

(In reply to :Gijs (he/him) from comment #18)

When this reproduces, does the network request in the network monitor appear complete?

I'm afraid I'm not sure what the network monitor has to do with any of this :-)
In any case, I've tried loading (and reloading) the about:logins page multiple times and no network requests are logged in the network monitor (both in the normal devtools and in the toolbox).

Huh. Yeah, I don't either. I would have expected requests for the style and image subresources, but none show up.

and we may be able to determine what's going on using MOZ_LOG-based logging.

I'd be glad to try that, but I'd likely need hand-holding as I'm not familiar with the process.
Are the steps here what I'm looking for? (aside from the parameters)
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Yes, the steps there are right, but we'll need ideas about what to log.

:aosmond or :tn, would you be able to help? There's an issue with an image in about:logins and/or about:newtab sometimes not showing up, and we're having trouble reproducing. Itiel can reproduce and I was hoping we could get some information about why the image is not there using MOZ_LOG and the imglib code. Is that a viable strategy, and/or is there another way of digging into this that I'm missing?

Comment 21

[Timothy Nikkel (:tnikkel)]

Imagelib mozlog modules that might be helpful PNGDecoder, imgRequest, JPEGDecoder. Another good way to investigate is to use about:memory in verbose mode and search for the uri of the image in question.

(leaving needinfo on me for now in case I think of something else)

Comment 22

[:Gijs (he/him)]

(In reply to Timothy Nikkel (:tnikkel) from comment #21)

Imagelib mozlog modules that might be helpful PNGDecoder, imgRequest, JPEGDecoder. Another good way to investigate is to use about:memory in verbose mode and search for the uri of the image in question.

(leaving needinfo on me for now in case I think of something else)

Thanks!

Itiel, could you try using those log modules and then opening the about:logins page once where it doesn't work (and saving that log, then stopping), and once where it does (and saving that log separately)? The logs will use pids in their filename, and you'll want to look at the ones for the process running about:logins (on nightly, visible in a tooltip for the tab; it'll be the same process for the duration of Firefox's uptime unless you're using fission, I think). I'm assuming we should be able to tell something from the difference in the logs.

It'd also be interesting to see what about:memory shows here, especially if the state of the icon not being visible persists if you open the about:memory tab and then switch back to the about:logins one.

Comment 23

[Itiel]

Attachment: Log captured from when the issue reproduces

Comment 24

[Itiel]

Attachment: Log captured from when the icon appears

Comment 25

[Itiel]

The icon filename in question is search-glass.svg.

Comment 26

[Itiel]

Attachment: aboutmemory icon appears

Comment 27

[Itiel]

Attachment: aboutmemory icon does not appear

Comment 28

[Itiel]

Attachment: aboutmemory icon appears

Comment 29

[Itiel]

The above screenshots don't change no matter how many times I test this, fwiw.
When the icon does not appear there's only one entry of the file in about:memoy on the main process.

Comment 30

[Itiel]

(In reply to :Gijs (he/him) from comment #22)

It'd also be interesting to see ... if the state of the icon not being visible persists if you open the about:memory tab and then switch back to the about:logins one.

No, doing so doesn't make any difference.

Comment 31

[:Gijs (he/him)]

Hm, I think log file writing isn't being allowed from the child still somehow - can you (temporarily!) set security.sandbox.content.level to 0 in about:config, restart Firefox, and then retry the moz logging?

I think the entries in the log file so far are from the use of the search glass in the URL bar (in the parent process). They look the same to me between the two logfiles.

Comment 32

[Itiel]

Attachment: Retry with sandbox disabled- Log captured from when the issue reproduces

Comment 33

[Itiel]

Attachment: Retry with sandbox disabled- Log captured from when the icon appears

Comment 34

[Itiel]

These logs are taken from the ones related to the about:logins process PID, let me know if the main process logs are also needed.

Comment 35

[:Gijs (he/him)]

Confusingly, the second ("successful") log doesn't mention the image at all. The "broken" log has this:

[Child 15396: Main Thread]: D/imgRequest 432721087 [this=000001884F30EA10] imgRequestProxy::OnLoadComplete (uri="chrome://browser/skin/search-glass.svg")
[Child 15396: Main Thread]: D/imgRequest 432721087 [this=000001884F30EA10] imgRequestProxy::RemoveFromLoadGroup
[Child 15396: Main Thread]: D/imgRequest 432721087 [this=0000000000000000] imgLoader::SetHasNoProxies (uri="chrome://browser/skin/search-glass.svg")
[Child 15396: Main Thread]: D/imgRequest 432721087 [this=000001884E980CA0] imgCacheEntry::SetHasNoProxies true (uri="chrome://browser/skin/search-glass.svg")
[Child 15396: Main Thread]: D/imgRequest 432721087 [this=000001884E994300] imgRequest::RemoveProxy -- load in progress.  canceling
[Child 15396: Main Thread]: D/imgRequest 432721087 [this=000001884E994300] imgRequest::Cancel {ENTER}
[Child 15396: Main Thread]: D/imgRequest 432721087 [this=000001884E994300] imgRequest::RemoveFromCache {ENTER}
[Child 15396: Main Thread]: D/imgRequest 432721087 [this=0000000000000000] imgLoader::RemoveFromCache entry
[Child 15396: Main Thread]: D/imgRequest 432721087 [this=0000000000000000] imgLoader::RemoveFromCache (entry's uri="chrome://browser/skin/search-glass.svg")
[Child 15396: Main Thread]: D/imgRequest 432721087 [this=0000000000000000] imgLoader::RemoveFromCache removing from tracker
[Child 15396: Main Thread]: D/imgRequest 432721087 [this=000001884E994300] imgRequest::SetIsCacheable (aInCache="0")

I don't know if that's bad or just a coincidence? I also don't know what'd cancel the request... Hopefully :tn and :aosmond have ideas.

Comment 36

[Itiel]

I managed to reproduce it on the New Tab page and this time not just the background image was missing, the background color was missing as well.
See attached.

Comment 37

[Itiel]

Attachment: New Tab with missing background image and color

Comment 38

[Itiel]

Attachment: How the New Tab should look like

Comment 39

[:Gijs (he/him)]

(In reply to Itiel from comment #36)

I managed to reproduce it on the New Tab page and this time not just the background image was missing, the background color was missing as well.
See attached.

Emilio, any idea what could be happening here? If the bg color is missing as well, perhaps this is style/layout-related instead of image-related? How could we get to the bottom of this?

Comment 40

[Emilio Cobos Álvarez [:emilio]]

The background + background-color are set using the same declaration:

background: var(--newtab-textbox-background-color) var(--newtab-search-icon) 12px center no-repeat;

So that seems at least somewhat plausible? But how do I reproduce this? I tried shift-reloading a bunch of times without success...

Comment 41

[:Gijs (he/him)]

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

The background + background-color are set using the same declaration:

background: var(--newtab-textbox-background-color) var(--newtab-search-icon) 12px center no-repeat;

So that seems at least somewhat plausible? But how do I reproduce this? I tried shift-reloading a bunch of times without success...

I don't think we have good STR - Itiel can reproduce it, and QA has seen it, but I've never managed to reproduce myself.

Is there any way for Itiel or QA to get useful info with logging or inspection of some kind?

Comment 42

[Emilio Cobos Álvarez [:emilio]]

Does showing up inspector "fix" it? If not, does inspecting the search input and toggling the background rule fix it? That'd hint at something.

While the image doesn't show, does getComputedStyle(..).background{Color,Image} show the right values?

Does removing this chunk of code (always setting it to false) fix it?

Comment 43

[Itiel]

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

Does showing up inspector "fix" it?

No.

If not, does inspecting the search input and toggling the background rule fix it? That'd hint at something.

Yes, see comment 8.

While the image doesn't show, does getComputedStyle(..).background{Color,Image} show the right values?

I'll test the first time I'll see it again. Setting needinfo on myself for that.

Does removing this chunk of code (always setting it to false) fix it?

So replacing the 3 lines with const bool reuseProxy = false, or just removing them would be enough?

Comment 44

[Emilio Cobos Álvarez [:emilio]]

Yes, const bool reuseProxy should do.

Comment 45

[Itiel]

Heh, so now it seems this can affect also XUL browser UI? See attached, the border next to the hamburger menu is missing.
Toggling this rule off an on fixed it:
https://searchfox.org/mozilla-central/rev/8698fade12984b9a6a43a85a287a5f17e8fd4ddf/browser/themes/shared/customizableui/panelUI.inc.css#41-48

emilio: for next time I see this (this is more visible as it's right in my face; I don't open about:logins that often), is the code snippet at comment 42 above still relevant or should I test for something else here?

Comment 46

[Itiel]

Attachment: No border next to the hamburger icon

Comment 47

[Emilio Cobos Álvarez [:emilio]]

(In reply to Itiel from comment #45)

emilio: for next time I see this (this is more visible as it's right in my face; I don't open about:logins that often), is the code snippet at comment 42 above still relevant or should I test for something else here?

Yeah, still relevant, though do try all the .borderImage* subproperties too. Depending on what the result is this seems either a CSS issue or a graphics issue...

Comment 48

[Emilio Cobos Álvarez [:emilio]]

But if it also happens on that border, that means that it's probably not an imagelib issue (as imagelib doesn't render the gradients)

Comment 49

[Itiel]

comment 46 happened again, but this time it went away when I opened the toolbox...

Comment 50

[Itiel]

Lately I'm seeing this in the new tab page, where tiles' text are disappearing when navigating to NTP back from a certain webpage. Note that this happens only to overflowing (ellipsized) text.
As soon as these tiles are being hovered, the text is appearing again.
I can't even inspect this as as soon as I open the devtools (or navigate to NTP when devtools is already open) the issue doesn't reproduce. :-(

Also, this can also be seen briefly when rapidly opening new tabs.

Comment 51

[:Gijs (he/him)]

(In reply to Itiel from comment #43)

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

Does showing up inspector "fix" it?

No.

If not, does inspecting the search input and toggling the background rule fix it? That'd hint at something.

Yes, see comment 8.

So this changed and now just opening the inspector fixes it - what does this hint at, Emilio? :-)

Comment 52

[Itiel]

Attachment: NTP screenshot with missing text

Comment 53

[Itiel]

Attachment: Screencast- Ctrl+T is being pressed on the NTP

Also note that while the issue happens and the text disappears, the ellipsis is still being shown but at the wrong spot, as if the directionality of the text is being lost along with the text itself.

Comment 54

[Emilio Cobos Álvarez [:emilio]]

(In reply to :Gijs (he/him) from comment #51)

So this changed and now just opening the inspector fixes it - what does this hint at, Emilio? :-)

So I thought this was going to be some CSS variable issue, but the about:logins icon is just a plain background-image: url(chrome://), so that's not it. Also since it doesn't seem to change dynamically, that probably means a bug with the painting side of things. Note that that's different from comment 53 however (that looks more like a translation / localization issue)

Comment 55

[Sergey Galich [:serg]]

Can't reproduce it on Fx116.