WebDriver/Meetings/2018-11-12

From MozillaWiki
Jump to: navigation, search

Agenda

  • Actions
  • Intermittents update
    • [fixed] Intermittent testing/marionette/harness/marionette_harness/tests/unit/test_window_close_content.py TestCloseWindow.test_close_browserless_tab | IOError: Process killed because the connection to Marionette server is lost (Bug 1501130)
    • [fixed] Permafail TvW /webdriver/tests/element_click/scroll_into_view.py | test_partially_visible_does_not_scroll[offset0] - In-test skip decorators are disallowed, please use WPT metadata to ignore tests (Bug 1505142)
    • [beta sim - needs fix for focus issue] Intermittent Linux Mn testing/marionette/harness/marionette_harness/tests/unit/test_screenshot.py TestScreenCaptureChrome.test_formats (Bug 1504201)
    • [needs new window command] Unwanted about:newtab page after navigation causes DOM interactions to fail
      • Intermittent testing/marionette/harness/marionette_harness/tests/unit/test_window_close_content.py TestCloseWindow.test_close_window_with_dismissed_beforeunload_prompt (Bug 1503027)

Minutes

Action items

ato
Haven’t done the deprecation document yet as I saw it as quite low priority.
But will do it by next week.

Intermittents update

whimboo
We had a week with two highly frequent intermittents, both of which we have fixed.
TestCloseWindow.test_close_browserless_tab
Frame script got reloaded after several subsequent child process changes
We cleared the list of pending commands afte rthe first process change, causing Marionette to hang.
We haven’t seen any side effects from not clearing this pending command list.
It makes us more stable when Gecko developers considers moving a tab to a new process in the future.
[…] triggering navigation request right after opening window, causing us to somehow return too early from navigation.
We could potentially fix the test itself, the mixin.
The best we have is pressing Control + T to open a new tab currently.
But this would get fixed by implementing a New Window command.
But it would take some time to do this work.
So I will go ahead and fix the test, to get rid of the intermittent.
Next, beta simulation and screenshot diff error.
I was then able to compare the screenshots, and it is related to focus of the window.
The case when it failed, there was a rich list box where the first item hadn’t been selected.
In the second screenshot, it was selected.
Gijs said we have to wait for the ChromeWindow to get deactiviated [?].
Last but not least, to finish with something positive, there was a TVw regression, caused by a change by ato.
ato
Yeah, that one was kind of strange. It only reproduced on the specific TC config.
You _can_ reproduce it locally by giving pytest’s parameterization an empty list.
This causes WPT to recognise it as a skip, causing an error.

Status updates

ato
While we had a regression with an intermittent, we also have lots of more passing tests on wpt.fyi.
However, I suspect there are some environment problems with both wpt.fyi and with WPT Travis for PRs.
gconf output is massie, and logs are getting cut off because Travis CI stops logging.
This sometimes makes it very hard to figure out why something is broken or instable.
Automatedtester
I thought we didn’t run via Travis CI anymore for PRs in relation to Firefox tests.
Lets check what taskcluster logs show and compare it with our jobs.
Maybe use the same Docker images.
ato
Yes, not quite sure why we are running both TC and Travis.
But I can’t really justify spending any time of investigating this.
AutomatedTester
Maybe ask James to have a look at it.
ato
I will do when the problem appears again.
whimboo
What you mentioned about the environment, there are still test failures in the window manipulation changes.
Especially regarding document.hidden in headless mode.
ato
This might be a bug in headless mode itself, so it would be ideal if we could ask bdahl to look at it.
For specific WMs which do not support minimizing windows this property will not be true, and this might be similar to headless for the moment.

ACTION ato: Report document.hidden problem with headless

whimboo
About the New Window command, and got it half-way working with tabs and Windows.
I listen for tabopen events, which I get and the framescript registered, but by this time the browser isn’t initialised so the outerWindowID is null.
This may conflict with the window tracking changes that ato is working on.
ato
Yes, I had this problem.
whimboo
A workaround I would go for now is to use the PollPromise and wait for the new window handle to appear in the list of handles
ato
That sounds perfectly fine for now.

Status updates

(Spoken status updates in bold.)

PTO/travel (🍂)

  • ato away Tuesday 13th and Wednesday 14th
  • whimboo: Mon (19th) or Tue (20th), and public holiday on Wed, 21st Nov
Retrieved from "https://wiki.mozilla.org/index.php?title=WebDriver/Meetings/2018-11-12&oldid=1203726"