Open Bug 1652823 Opened 4 years ago Updated 6 months ago

The fixed header on soundcloud.com does not dissapear when I switch to a tab containing another fixed header (azbukasantehniki.ru)

Categories

(Core :: Graphics: WebRender, defect)

79 Branch
x86_64
Windows 10
defect

Tracking

()

Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox78 --- unaffected
firefox79 --- affected
firefox80 --- affected

People

(Reporter: haypro.narek, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: correctness)

Attachments

(3 files)

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

Steps to reproduce:

  1. Open tab https://azbukasantehniki.ru/catalog/kotly_otopleniya_dlya_chastnogo_doma/kotel_gazovyy_nastennyy/
    Scroll a bit down till the fixed header appears.
  2. Create a new tab and log in and play music as usual on https://soundcloud.com/discover
  3. Make sure you have a fixed dark header on soundcloud.
  4. Now switch the tab to azbukasantehniki.ru

Actual results:

The dark header of soundcloud.com does not disappear after switching to azbukasantehniki.ru. I can see it over azbukasantehniki.ru. Again: I see the upper bar from soundcloud.com over the another site azbukasantehniki.ru.
See here: https://youtu.be/rLcRikocbl8

Expected results:

The upper bar should disappear.

Component: Untriaged → Graphics
Product: Firefox → Core
See Also: → 1638490

Can you attach the contents of your about:support as a text file?

Flags: needinfo?(haypro.narek)
Blocks: wr-79
Severity: -- → S3
Priority: -- → P3
Attached file about:support
Flags: needinfo?(haypro.narek)

I haven't been able to reproduce locally so far (tested on a Mac and a Windows machine). Jessie, how easy is it to reproduce - was it happening regularly or just once?

Would you be able to set gfx.webrender.compositor to false, restart the browser (need to do an exit from dock on Mac), and see if you can reproduce then? (I suspect that will stop it occurring - not a good fix - but would help narrow down what part of the code may be causing it). Remember to change that pref back to normal after testing though!

Flags: needinfo?(gwatson)

I reproduced this pretty easily yesterday, but am not able to do so yet again today. Will keep trying.

haypro.narek, does this reproduce for you easily, every time you visit these two pages? Do you ever see it with other websites?

Flags: needinfo?(haypro.narek)

We had two regressions that looked similar:
Bug 1653413 caused regressions with DirectComposition on Win10.
Bug 1640960 caused regressions on macOS.
Comment 0 might have been caused by Bug 1653413, and comment 2, comment 10 by bug 1640960.

Blocks: wr-80
No longer blocks: wr-79
Component: Graphics → Graphics: WebRender
Flags: needinfo?(haypro.narek)
OS: Unspecified → All
Regressed by: 1640960
Hardware: Unspecified → All

Sorry, I have to correct. Different bugs have been mixed:
comment 0 is Win10 WebRender on 79.0b4. Therefore it can't be bug 1653413 or bug 1640960.
comment 2 and comment 10 were caused by bug 1640960.

Blocks: wr-79
No longer blocks: wr-80
OS: All → Windows 10
No longer regressed by: 1640960
Hardware: All → x86_64

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Priority: P3 → --
Blocks: wr-80
No longer blocks: wr-79

I can reproduce this in 80.0b8. Here is another demonstration of the bug: https://youtu.be/LCRGRy5n4kk

Unfortunately I can not recognize the exactly conditions to reproduce it.

Keywords: correctness
No longer blocks: wr-80
Blocks: wr-81

@ktaeleman: try repro

Flags: needinfo?(ktaeleman)
No longer blocks: wr-81

Still easily reproduces on latest nightly with repro steps of reporter.
@Glenn: gfx.webrender.compositor false does not show the issue, so it must be related to this.

Let me know if you want me to generate some logging or so!

Flags: needinfo?(ktaeleman) → needinfo?(gwatson)

I can reproduce this bug on macOS.

I haven't been able to reproduce locally yet, but will try again today / tomorrow. Markus is going to try and look at it this week as he is able to reproduce locally.

Flags: needinfo?(gwatson)

I can no longer reproduce this :(

@Kris try repro again

Flags: needinfo?(ktaeleman)
No longer blocks: gfx-82
No longer blocks: gfx-83
Flags: needinfo?(ktaeleman)

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: