Remove html/semantics/forms/the-input-element/range-restore-oninput-onchange-event.html

[nt1m]

** Test List **

html/semantics/forms/the-input-element/range-restore-oninput-onchange-event.html

** Rationale **

It does pass on WebKit infrastructure: https://searchfox.org/wubkat/source/LayoutTests/imported/w3c/web-platform-tests/html/semantics/forms/the-input-element/range-restore-oninput-onchange-event-expected.txt

It does not pass on wpt.fyi however, quoting @cdumez, because:

The reason for that is that the back/forward cache is enabled in Safari but disabled in WebKitTestRunner. The test times out in Safari because it is never getting a load event on back navigation, because the we restored the page from the back/forward cache. The test passes in Chrome and Firefox because they don't allow back/forward caching of pages with an opener.

cc @jensimmons

[foolip]

Can this test be written to be compatible with bfcache instead?

[jgraham]

Or we could use a cross-browser way to inhibit bfcache.

[cdumez]

HTTPS + Cache-Control: no-store would inhibit the bfcache for WebKit (and likely other browsers)

[foolip]

Here's the test:
https://github.com/web-platform-tests/wpt/blob/master/html/semantics/forms/the-input-element/range-restore-oninput-onchange-event.html

A new window is window.open()'d and I guess the problem is that w.history.back() never ends up firing an event. But are there other ways of checking that the navigation happened, that makes the test work whether it's in bfcache or not? The "pageshow" event perhaps?

[foolip]

@mfreed7 @josepharhar do either of you have experience with this test, can you give input?

[jgraham]

I thought adding an unload handler would be enough to prevent bfcache, but I'm not sure I'm correct.

@smaug---- your input here would be very useful.

[cdumez]

I thought adding an unload handler would be enough to prevent bfcache, but I'm not sure I'm correct.

Not true in WebKit.

[cdumez]

Here's the test: https://github.com/web-platform-tests/wpt/blob/master/html/semantics/forms/the-input-element/range-restore-oninput-onchange-event.html

A new window is window.open()'d and I guess the problem is that w.history.back() never ends up firing an event. But are there other ways of checking that the navigation happened, that makes the test work whether it's in bfcache or not? The "pageshow" event perhaps?

Listening of the "pageshow" event would indeed detect the navigation even if coming from the bfcache. However, I don't think this is the way to fix this test since it validates form restoration on history traversal and expected certain form control events. If the page came out of the bfcache then there would be no form restoration or form control events since the form controls would come out of the cache as-is with their last values already in there.

I think the way to fix this test is to somehow opt out of bfcache. The most reliable way I know is HTTPS + Cache-Control: no-store.

[foolip]

Alright, can someone experiment with HTTPS + Cache-Control: no-store? Is it resources/${type}-restore-events.html that would have to be served with that header?

[cdumez]

Alright, can someone experiment with HTTPS + Cache-Control: no-store? Is it resources/${type}-restore-events.html that would have to be served with that header?

I guess I can experiment since WebKit is the one bf caching.

[cdumez]

web-platform-tests/wpt#35341

[cdumez]

I had to rename the test to make it https. Does anything need to be done to update the test name in Interop?

[nt1m]

web-platform-tests/wpt-metadata#2932

[nt1m]

Sounds like there isn't anything else to do here, closing. Thanks Chris!

[foolip]

Thanks for helping sort this out, @cdumez and @nt1m!

[vinhill]

Since this change, the test is failing on Firefox, see bug 1783245 and this commit.

Also, if this test is aimed at restoring persistent state, we should assert that bfcache is not active (e.g. by changing the value of a span) and make this test optional.

@cdumez do you know of other ways to disable bfcache in Safari? I'm still investigating why no-store makes the test fail on Firefox. But to my knowledge, the HTML Spec defines no interaction between no-store and bfcache and browsers behave differently for no-store.

[hsinyi]

Reopen this for reviewing and addressing vinhill's comment. Thanks!

[petervanderbeken]

As vinhill noted, this test was working correctly in Firefox: the page didn't go into the BFCache for us because it has an opener, and we restored form values correctly. Adding no-store broke it for Firefox because no-store disables form restoration in Firefox.

This area isn't really specified well in HTML, and we are considering aligning our form restoration behaviour in that case with other browsers at some point. But it still seems wrong to change a test to work in WebKit and simultaneously break it in Firefox because of non-speced behaviours that are unrelated to the behaviour that the test is checking.

I don't think there's currently a good way to disable BFCache described in the specs. @smaug---- pointed out to me that the HTML spec does mention active WebSocket objects in https://html.spec.whatwg.org/#dom-pagetransitionevent-persisted-dev, but I'm not sure whether that's supported cross-browser too.

[foolip]

This is the test on wpt.fyi:
https://wpt.fyi/results/html/semantics/forms/the-input-element/range-restore-oninput-onchange-event.https.html