1510305 - document.hidden reports false when ChromeWindow.windowState says it is minimised

Status: RESOLVED FIXED

(Firefox :: Headless, defect, P3)

Description

[Andreas Tolfsen ❲:ato❳]

In enabling WebDriver WPT tests (the Wd job on TC) in headless mode
[1] and when working on some window manipulation changes [2], we
discovered that the document.hidden DOM property always reports
false even when the ChromeWindows windowState says it is minimised.

This can be reproduced locally with this command:

> % ./mach wpt --headless testing/web-platform/tests/webdriver/tests/minimize_window/minimize.py

You will see tests failing with this error:

> >       assert document_hidden(session)
> E       assert False
> E        +  where False = document_hidden(<Session 5b8d7038-6be2-46db-afeb-3b22a08c74df>)

document_hidden is a helper function that polls document.hidden a
few times until it is true or until a timeout of three seconds is
reached.  We would like to get rid of this poller when we can rely
on document.hidden and in knowing the window manipulation code in
Marionette is more reliable.

I can also reproduce this problem when I X11 forward the Firefox
window to my macOS terminal, presumably because XQuartz does not
emit iconification events to the Firefox process across system
boundaries, so this is possibly not relevant to this bug.

  [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1493907#c14
  [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1492499

Comment 1

[Andreas Tolfsen ❲:ato❳]

This can be debugged by modifing the WebDriver:MinimizeWindow command
found here:
https://searchfox.org/mozilla-central/source/testing/marionette/driver.js#2988-3006

To surface the Marionette logs, you can do this:

> % ./mach wpt --webdriver-arg=-vv --headless testing/web-platform/tests/webdriver/tests/minimize_window/minimize.py

Comment 2

[Brendan Dahl [:bdahl]]

Running in normal mode (non-headless), I also see:

>>  0:13.29 pid:30576 1543347507887	Marionette	TRACE	0 -> [0,33,"WebDriver:MinimizeWindow",{}]
>>  0:17.80 pid:30576 1543347512390	Marionette	WARN	TimedPromise timed out after 4500 ms: stacktrace:

Maybe this isn't a headless only bug?

Comment 3

[Andreas Tolfsen ❲:ato❳]

It could be focusmanager related.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Brendan Dahl [:bdahl] from comment #2)
> Running in normal mode (non-headless), I also see:
> 
> >>  0:13.29 pid:30576 1543347507887	Marionette	TRACE	0 -> [0,33,"WebDriver:MinimizeWindow",{}]
> >>  0:17.80 pid:30576 1543347512390	Marionette	WARN	TimedPromise timed out after 4500 ms: stacktrace:
> 
> Maybe this isn't a headless only bug?

In that case it is a problem with Marionette with stopping an API call due to a custom timeout, which should not happen. I summarized everything on bug 1517414, which might also fix this bug.

Comment 5

[Andreas Tolfsen ❲:ato❳]

(In reply to Henrik Skupin (:whimboo) from comment #4)

> (In reply to Brendan Dahl [:bdahl] from comment #2)
> 
> > Running in normal mode (non-headless), I also see:
> > 
> > >>  0:13.29 pid:30576 1543347507887 Marionette TRACE 0 ->
> > >>  0:1[0,33,"WebDriver:MinimizeWindow",{}] 7.80 pid:30576
> > >>  0:11543347512390 Marionette WARN TimedPromise timed out
> > >>  0:1after 4500 ms: stacktrace:
> > 
> > Maybe this isn't a headless only bug?
> 
> In that case it is a problem with Marionette with stopping an
> API call due to a custom timeout, which should not happen. I
> summarized everything on bug 1517414, which might also fix this
> bug.

Marionette doesn’t interfere with the return value of
document.hidden or ChromeWindow#windowState, so I think it is more
likely that it can be focusmanager related.  The timeout here is
irrelevant, since the bug is about document.hidden being false when
windowState is STATE_ NORMAL.

In a normal Firefox session you can run this test in the Browser
Toolbox, then minimise the window before the two seconds have
elapsed:

> setTimeout(() => { console.log(window.windowState); console.log(document.hidden); }, 2000);

This should report, when the window is iconified:

> 2 false

The magic number 2 is the STATE_MINIMIZED documented in
https://developer.mozilla.org/en-US/docs/Web/API/Window/windowState.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: minimized Marionette test

You are right. The timeout doesn't change anything, and is also unrelated for this bug. I investigated that and made notes on bug 1507067 comment 3.

(In reply to Brendan Dahl [:bdahl] from comment #2)
> Running in normal mode (non-headless), I also see:
> 
> >>  0:13.29 pid:30576 1543347507887	Marionette	TRACE	0 -> [0,33,"WebDriver:MinimizeWindow",{}]
> >>  0:17.80 pid:30576 1543347512390	Marionette	WARN	TimedPromise timed out after 4500 ms: stacktrace:
> 
> Maybe this isn't a headless only bug?

You may be confused here due to the complexity and amount of log output from the wdspec test. As such I created a minimized test for Marionette. Just save it and run it via `mach marionette test -vv --gecko-log - %test_file%`.

Only for headless mode the output is always `False`, while otherwise it is `True`. It would be great if you could have a look at it again. Thanks!

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

The same also applies to https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilityState, which is always reported as visible. Maybe this is due to that no visibilitychange event is getting fired on the active tab, when calling minimize() in headless mode? That's what I just noticed when working on bug 1520302.

Brendan, it would be great if you could have a look at this. Thanks!

Comment 8

[Brendan Dahl [:bdahl]]

I took a quick look and was able to reproduce with your test case and couldn't find any obvious issues in headless. The focus manager related code always seems to take awhile to dig into, but hopefully I'll have some time this week or next. Leaving the need info as a reminder.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As what I just have seen too, also docShellIsActive isn't getting updated to false. So maybe minimizing the window in headless mode doesn't actually work at all?

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

With bug 1562025 being fixed now this is no longer a problem! This is wonderful.