As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 1330348 - Make forward- and backward commands synchronous
: Make forward- and backward commands synchronous
Status: NEW
Product: Testing
Classification: Components
Component: Marionette (show other bugs)
: Version 3
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
Blocks: webdriver
  Show dependency treegraph
Reported: 2017-01-11 08:21 PST by Andreas Tolfsen ‹:ato›
Modified: 2017-01-17 08:27 PST (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Andreas Tolfsen ‹:ato› 2017-01-11 08:21:32 PST
Tests using the forward- and backwards commands in Marionette are known to cause intermittents.  We suspect this is because they are not implemented in a synchronous manner, e.g. they don’t wait for the document to reach the expected state before returning.

Because navigating backwards and forwards may either reload a document from bfcache or navigate internally in a document (if push state or internal anchors have been used), we _do not_ expect a document load event to occur.  I’m not entirely sure what the right fix is, but suspect the fix might involve updating the WebDriver standard to be more specific.
Comment 2 User image Andreas Tolfsen ‹:ato› 2017-01-11 08:24:46 PST is for fixing the Refresh command.  The refresh command, in contrast to Back and Forward, always expect the document to reload and for the document load events to fire.
Comment 3 User image Henrik Skupin (:whimboo) 2017-01-11 08:31:06 PST
Keep in mind that also JS code can trigger navigating back and forward. For those and like other commands (click, keypress) which cause a load of a page, it will be hard to check that in Marionette server with the current algorithm.

In Mozmill I solved this problem by assigning a uuid for each page load. Once a page gets unloaded it gets reset (and the current value backup'ed), and once loaded a new value is set. With that we were able to see that a page load was happening for a tab. So this was able to also handle external page loads triggered by whatever the user is doing.

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