Closed Bug 1553171 Opened 5 years ago Closed 5 years ago

Since Nightly v68 the firefox window does not get refreshed when switching to firefox workspace where firefox is inactive.

Categories

(Core :: Graphics: WebRender, defect)

68 Branch
Desktop
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1514148
Tracking Status
firefox67 --- disabled
firefox68 --- disabled
firefox69 --- disabled
firefox70 --- disabled

People

(Reporter: myaccounts, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Attached image snap2.png (deleted) —

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

I use i3 as wm. I have firefox nightly v68.0a1 on workspace 1 and a second window, which is active (so the firefox window is inactive!). Now I switch to another workspace. When switching back to workspace 1, the firefox window is still inactive (as expected).

I added an image demonstrating the issue. In the black firefox area you see how I executed the screenshot from the previous workspace. The terminal screen was covering parts of the firefox window (coordinatewise on the screen).

Actual results:

The firefox window does not get refreshed. E.g. when my other workspace was black, the (whole) firefox window remains black. On certain pages it refreshes after some seconds. Prime example: Youtube. If I have a video running and do the steps, it will instantly refresh. If the video is not running, it will take seconds to refresh. The actual time varies.

I cannot reproduce it with "plain" firefox.

Expected results:

The window refresh should have happened immediately on switching to the workspace!

I just upgraded to nightly v69 and the bug is still present.

Hey famfop,

Could you please run mozregression to check which bug patch regressed this? Here are the instructions for this: https://mozilla.github.io/mozregression/

Meanwhile, I am adding this issue to a component so the developers can check it out. Thanks for the report!

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

(In reply to Timea Babos from comment #2)

Hey famfop,

Could you please run mozregression to check which bug patch regressed this? Here are the instructions for this: https://mozilla.github.io/mozregression/

Meanwhile, I am adding this issue to a component so the developers can check it out. Thanks for the report!

Hi Timea,

I just ran the tool and got the following output to stdout:
11:49.72 INFO: Last good revision: 1664505ad313eff325d6dbc62bce5357fac19b90
11:49.72 INFO: First bad revision: 34e912d9305a292318edc31931bf354c5221ec6a
11:49.72 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1664505ad313eff325d6dbc62bce5357fac19b90&tochange=34e912d9305a292318edc31931bf354c5221ec6a

Is this output sufficient?

Very helpful!
Unfortunately I don't have a virtual machine to test this out, but in order to update the flags and make it clear, Firefox Nightly (v69) and Beta (v68) are affected, right? Could you please also check Firefox Release version?

Moving this over to WebRender due to the regression range found in Comment 3.

Hey Andrew, could you please take a look at this when you have the time?
Thank you!

Has Regression Range: --- → yes
Component: Widget: Gtk → Graphics: WebRender
Flags: needinfo?(aosmond)
Keywords: regression
OS: Unspecified → Linux
Regressed by: 1543217
Hardware: Unspecified → Desktop
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(aosmond)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: