Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1725308 - [Wayland] Sometimes a page renders initially blank/white with GNOME fractional scaling
Summary: [Wayland] Sometimes a page renders initially blank/white with GNOME fractiona...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ffwayland
TreeView+ depends on / blocked
 
Reported: 2019-06-29 10:05 UTC by Jan Vlug
Modified: 2019-11-05 12:55 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 12:55:02 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
About box nightly (152.07 KB, image/png)
2019-07-01 07:13 UTC, Jan Vlug
no flags Details
Screencast showing blank page and dragging window forcing to draw page (11.49 MB, video/webm)
2019-07-02 12:03 UTC, Jan Vlug
no flags Details
about support output (16.68 KB, text/plain)
2019-07-02 12:08 UTC, Jan Vlug
no flags Details

Description Jan Vlug 2019-06-29 10:05:28 UTC
Sometimes a page renders blank/white when I open a page from a link in Firefox in a new tab, or from an external application.

I always use Firefox in a maximized window on Wayland. Grabbing the Firefox window a the title bar to move it, and immediately moving it back to maximized state forces Firefox to render the page correctly.

I do not know how to exactly reproduce this bug, but it happens several times a day.

I always have lots of tabs open. I experience this bug only on my system where I have fractional scaling enabled on a HiDPI display. This system has also a regular display with 100% scaling.

firefox-wayland.x86_64 - 67.0.4-1.fc30

Comment 1 Jan Vlug 2019-06-29 10:11:14 UTC
Probably related to (or even duplicate of) bug 1709852.

Comment 2 Martin Stransky 2019-07-01 06:18:06 UTC
Can you please try latest nightly? how-to is here - https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries
Thanks.

Comment 3 Jan Vlug 2019-07-01 06:56:54 UTC
I downloaded a nightly from here: https://www.mozilla.org/en-US/firefox/channel/desktop/
How do I start Firefox nightly with Wayland as back-end?

I did:
$ export GDK_BACKEND=Wayland
$ ./firefox -ProfileManager -no-remote

But this resulted in:

(firefox:9550): Gdk-CRITICAL **: 08:52:54.644: gdk_screen_get_monitor_scale_factor: assertion 'GDK_IS_SCREEN (screen)' failed

(firefox:9550): Gtk-CRITICAL **: 08:52:54.646: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(firefox:9550): Gtk-CRITICAL **: 08:52:54.646: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(firefox:9550): Gtk-CRITICAL **: 08:52:54.646: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
ExceptionHandler::GenerateDump cloned child 9575
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Segmentation fault (core dumped)

The same happens for the beta 68.0b14.

Comment 4 Martin Stransky 2019-07-01 07:05:13 UTC
That means you have old nightly version installed. Run without GDK_BACKEND (i.e. under X11), go to menu help -> about and update nightly from there and restart. Then you should be  able to run it under wayland, I tested it now.

Comment 5 Jan Vlug 2019-07-01 07:13:25 UTC
Created attachment 1586158 [details]
About box nightly

Strange, it seems that I have the latest nightly (see screenshot of the about box).

Comment 6 Martin Stransky 2019-07-01 08:08:47 UTC
I have the same build and run it as MOZ_ENABLE_WAYLAND=1 ./firefox and Wayland backend works for me.

Comment 7 Jan Vlug 2019-07-01 08:27:21 UTC
OK, this works. I will test for a while and report back later.

Comment 8 Jan Vlug 2019-07-01 08:35:17 UTC
This bug is still present in the 69.0a1 (2019-06-30) (64-bit) nightly.
I do get some SELinux security alerts when using the nightly. But I guest that is unrelated.

Comment 9 Jan Vlug 2019-07-01 09:44:13 UTC
This is the SELinux issue: bug 1723308

Comment 10 Martin Stransky 2019-07-02 08:29:56 UTC
GDK_BACKEND=Wayland is wrong, it should be "wayland", but MOZ_ENABLE_WAYLAND is the best way how to enable wayland.

Comment 11 Jan Vlug 2019-07-02 10:13:13 UTC
I'm running nightly 69.0a1 (2019-07-01) (64-bit) now with:
MOZ_ENABLE_WAYLAND=1 ./firefox
and the issue just happened again. I do have quite a lot of extensions, so I will use the nightly with a brand new profile and see if I will still see this issue.

Comment 12 Martin Stransky 2019-07-02 10:35:17 UTC
(In reply to Jan Vlug from comment #11)
> I'm running nightly 69.0a1 (2019-07-01) (64-bit) now with:
> MOZ_ENABLE_WAYLAND=1 ./firefox
> and the issue just happened again. I do have quite a lot of extensions, so I
> will use the nightly with a brand new profile and see if I will still see
> this issue.

Sure, please reopen if you have some closer info. Also please attach content of about:support page.
Thanks.

Comment 13 Jan Vlug 2019-07-02 12:03:06 UTC
Created attachment 1586669 [details]
Screencast showing blank page and dragging window forcing to draw page

I used GNOME screencast to make a screencast of the white page, and how dragging the Firefox window by it's title bar makes the page render. I guess that everything was extra sluggish because GNOME screencast was running.

Comment 14 Jan Vlug 2019-07-02 12:08:17 UTC
Created attachment 1586670 [details]
about support output

about:support output attached.
Note that I did enable my Firefox Sync account on this nightly, and left enabled several extensions (as you can see in the about:support file.

Comment 15 Jan Vlug 2019-07-02 13:36:46 UTC
I just noticed that pressing F11 (entering full screen mode) also forces the page to render.

Here below an excerpt from the messages printed in terminal where I started Firefox. Maybe this is useful, I do not know whether they were printed at the same time of the white screen or not:

[jan@xxx firefox]$ MOZ_ENABLE_WAYLAND=1 ./firefox -Profilemanager
Attempting load of libEGL.so

###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

Attempting load of libEGL.so
Attempting load of libEGL.so
WebGL(0x7f3db6e61800)::ForceLoseContext
WebGL(0x7f3db6e62000)::ForceLoseContext
WebGL(0x7f3daff23800)::ForceLoseContext
WebGL(0x7f3db697d800)::ForceLoseContext

(firefox:27219): Gdk-WARNING **: 14:16:42.860: Tried to unmap the parent of a popup
[Parent 27219, Gecko_IOThread] WARNING: pipe error (244): Connection reset by peer: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358
Attempting load of libEGL.so

Comment 16 Jan Vlug 2019-07-03 17:41:45 UTC
I am not sure, but it could be that this bug only happens when you have unchecked Title Bar in Customize...

Comment 17 Martin Stransky 2019-07-03 18:32:09 UTC
(In reply to Jan Vlug from comment #16)
> I am not sure, but it could be that this bug only happens when you have
> unchecked Title Bar in Customize...

Can you please check that?

Comment 18 Jan Vlug 2019-07-03 20:35:38 UTC
I'm sure that the bug happens when Firefox has no title bar. I will enable the title bar from now on, and see if the bug happens then as well, but proving the non-existence of this bug is more difficult, because I do not know how to reproduce the bug. I have the impression though that clicking a link in an external application (in my case usually Thunderbird) sometimes triggers the bug, but definitely not always.

Comment 19 Jan Vlug 2019-07-03 20:47:37 UTC
Now I was experimenting between switching between the Title bar enabled and disabled, I noted another issue. When I have a correctly rendered tab open in Firefox without Title bar, and then go to Customize... and enable the Title bar and click Done, the page that was previously rendered correctly changed into a white page with a spinner in the center (note that this spinner is not visible in the initial bug that is reported by this bug report). Using: 69.0a1 (2019-07-03) (64-bit). The tabs stays white with the spinner even if I resize the Firefox window, reload the page or try to load another page.

Changing from enabled Title bar to disabled Title bar triggers the same issue.

Comment 20 Jan Vlug 2019-07-04 21:50:12 UTC
I used the whole day Firefox with the Title bar enabled, and all pages were rendered correctly until now.

Comment 21 Martin Stransky 2019-11-05 12:55:02 UTC
This should be already fixed in Fedora 31 / Firefox 70.


Note You need to log in before you can comment on or make changes to this bug.