Update tests for fullscreen event targets (element or document)#6017
Conversation
Firefox (nightly)Testing web-platform-tests at revision 1cb8ea1 All results2 tests ran/fullscreen/api/element-request-fullscreen-not-allowed.html
/fullscreen/interfaces.html
|
Firefox (nightly)Testing web-platform-tests at revision 2e09fc8 All results1 test ran/fullscreen/api/element-request-fullscreen-not-allowed.html
|
Sauce (safari)Testing web-platform-tests at revision 1cb8ea1 All results2 tests ran/fullscreen/api/element-request-fullscreen-not-allowed.html
/fullscreen/interfaces.html
|
Sauce (safari)Testing web-platform-tests at revision 2e09fc8 All results1 test ran/fullscreen/api/element-request-fullscreen-not-allowed.html
|
Chrome (unstable)Testing web-platform-tests at revision 1cb8ea1 All results2 tests ran/fullscreen/api/element-request-fullscreen-not-allowed.html
/fullscreen/interfaces.html
|
Chrome (unstable)Testing web-platform-tests at revision 59f2307 All results1 test ran/fullscreen/api/element-request-fullscreen-not-allowed.html
|
Sauce (MicrosoftEdge)Testing web-platform-tests at revision 1cb8ea1 All results2 tests ran/fullscreen/api/element-request-fullscreen-not-allowed.html
/fullscreen/interfaces.html
|
|
@bobholt, the result comments are duplicated on this PR, is this a known issue? |
|
@foolip: Not a known issue. As far as I can tell, it hasn't happened before (or in the PR since). For this to have happened, prbuildbot would have had to been invoked twice within very short order (otherwise the comments would have existed, and the bot's check for existing comments would have caught them). I think we can see this born out in the matching timestamps in the duplicate comments. The only way I could explain that occurrence is if Travis somehow fired the webhook twice. |
Presumably that can happen? If the server is very slow to respond, maybe it retries after a while, but the first request actually reached the system as well and just didn't get a reply? |
I've seen Travis (rarely) respond twice to commands that are only invoked once in the build script, so it's not outside the realm of possibility to me that it could have fired 2 webhook If it waited any appreciable time between the two webhooks, we should only have seen one comment, as the previous comments would have already been in place (and found and edited by the script). That said, I doubt Travis does any kind of webhook retry. It seems very "fire and forget." It's hard to tell, though, because they don't provide a UI into sent webhooks like GitHub does. |
2e32b23 to
24e3a1c
Compare
|
@upsuper, would you mind reviewing this as well? |
zcorpan
left a comment
There was a problem hiding this comment.
LGTM, but could have more coverage, in particular: if element is connected but its node document is not document, is not tested, is it?
| assert_equals(iframeDoc.fullscreenElement, null); | ||
| assert_equals(document.fullscreenElement, null, "outer fullscreen element"); | ||
| assert_equals(iframeDoc.fullscreenElement, null, "inner fullscreen element"); | ||
| assert_equals(event.target, document, "event target"); |
There was a problem hiding this comment.
@zcorpan, this and the same bit in element-request-fullscreen-and-remove-manual.html tests the event targeting.
|
Is there test for checking what happens when the fullscreen element or any of its ancestor is removed from the document? |
|
No, I'm now updating tests under model/ for that. |
|
OK, I've tweaked the existing tests under model/ and added one new one. Please take another look. |
|
Will have a look tomorrow (hopefully). |
|
Thanks. LGTM |
Follows whatwg/fullscreen#90.