Some input field are black when taking screenshot in headless mode

NEW
Unassigned

Status

()

P3
normal
a year ago
4 months ago

People

(Reporter: kristian, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

a year ago
Created attachment 8891803 [details]
Script to take a screenshot of facebook in head/headless mode.

Hello

I just tried taking a screenshot in headless mode with the newest Nightly (2017-07-30) and Geckodriver 0.18.0 with help from the Selenium (3.4.3) Python sdk.

And it seems to work pretty well, but some of the input fields are black when taking screenshot in headless mode. See attached attachment.


Regards Kristian
(Reporter)

Comment 1

a year ago
Created attachment 8891804 [details]
Screenshot of facebook.com taking in non-headless mode
(Reporter)

Comment 2

a year ago
Created attachment 8891805 [details]
Screenshot of facebook.com taking in headless mode
Hi Kristian, would you mind trying again with the latest Nightly? I believe the patches I landed for bug 1373739 will have addressed this (specifically, I implemented the NativeLookAndFeel hooks for headless mode).
Flags: needinfo?(klausenbusk)
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 4

a year ago
Hello

The color is correct now, but I noticed that the dropdowns button is missing.
I will attach a picture so you can see.

Regards Kristian
Flags: needinfo?(klausenbusk)
(Reporter)

Comment 5

a year ago
Created attachment 8895312 [details]
Screenshot of facebook.com taking in headless mode

Screenshot taken with latest Nightly, after https://bugzilla.mozilla.org/show_bug.cgi?id=1385711 was applied to Nightly.
Attachment #8891805 - Attachment is obsolete: true
Thanks! It looks like this is a result of an nsITheme object not being created in headless mode under GTK [0], as nsNativeThemeGTK depends on APIs which we can't access in headless mode. As a result this shouldn't affect the Windows and macOS platforms.

I can reproduce the behavior in the screenshot outside of headless mode by applying the following small patch to disable nsITheme creation:

diff --git a/widget/gtk/nsWidgetFactory.cpp b/widget/gtk/nsWidgetFactory.cpp
index 3c8bc02..7a8d4ed 100644
--- a/widget/gtk/nsWidgetFactory.cpp
+++ b/widget/gtk/nsWidgetFactory.cpp
@@ -87,7 +87,7 @@ static nsresult
 nsNativeThemeGTKConstructor(nsISupports *aOuter, REFNSIID aIID,
                             void **aResult)
 {
-    if (gfxPlatform::IsHeadless()) {
+    if (true || gfxPlatform::IsHeadless()) {
         return NS_ERROR_NO_INTERFACE;
     }
     nsresult rv;

We have existing fallback paths for when a nsITheme object is unavailable, but it looks like they're not being exercised on any of Windows, macOS, or Linux under normal conditions. For example, the width of the dropdown button is determined by the width of the scrollbar in the dropdown list. This is measured by GetNondisappearingScrollbarWidth [2], which boils down to asking the vertical scrollbar nsBoxFrame what its preferred width is [3]. Normally this ends up being calculated using nsITheme::GetMinimumWidgetSize which calls out to platform-specific code; in the absence of a theme, we rely on the computed size from the CSS applied to the scrollbar XUL element and its children. Note that vertical scrollbar thumbs have a minimum height assigned [4], but no minimum width, so the computed scrollbar width ends up being 0, and the dropdown buttons end up being 0-width. Adding a minimum width to thumb[orient="vertical"] causes the dropdown buttons to show up under headless mode. It also causes the scrollbar to show up along the side, but there's no color set for the slider, so it's just a white strip. And so on...

[0] http://searchfox.org/mozilla-central/rev/0f16d437cce97733c6678d29982a6bcad49f817b/widget/gtk/nsWidgetFactory.cpp#90-92

[1] http://searchfox.org/mozilla-central/rev/0f16d437cce97733c6678d29982a6bcad49f817b/layout/forms/nsComboboxControlFrame.cpp#861-878

[2] http://searchfox.org/mozilla-central/rev/0f16d437cce97733c6678d29982a6bcad49f817b/layout/generic/nsGfxScrollFrame.cpp#1217

[3] http://searchfox.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp#1197

[4] http://searchfox.org/mozilla-central/rev/c329d562fb6c6218bdb79290faaf015467ef89e2/toolkit/themes/windows/global/xulscrollbars.css#49
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.