Add pref-gated methods for testing activation

[Manishearth]

From script, currently you can only trigger synthetic activations with .click(). However, there is a lot of intricacy around activation that is not observable (and thus not testable from JS), which we really should be testing. PRs like #11781 generally add an HTML test, but I'd prefer to have servo-specific WPT tests here. Eventually, webdriver would be the solution, but so far we don't have that up yet.

I'd like to do something similar to #12322 (comment), use a testing pref that enables methods on elements that lets you trigger activation, cancel activation, and check if something is activatable, among any other functionality that tests may find useful. Then, of course, we should write tons of tests for activation corner cases that use these 😄

cc @jdm @Ms2ger

@sjmelia: Would you like to work on this?

[izgzhen]

I bumped into a tidy problem saying that I should add spec link comment to our special methods. Should I modify the linter, or there is another workaround?

[Manishearth]

Just say "internal testing method" and have the tidy linter skip such strings

[izgzhen]

@Manishearth

servo/python/tidy/servo_tidy/tidy.py

Line 559 in 0766770

if "// check-tidy: no specs after this line" in line:

I found this can work: // check-tidy: no specs after this line

[sjmelia]

I would absolutely love to work on this!

The end goal w.r.t. PR #11781 would be a test that looks something like this:

element.enter_activation_state(); // only valid when dom.testing.element.activation.enabled:true
assert_true(document.querySelector(':active') === element, 
            'Element was not given pseudoselector');
element.exit_activation_state();

My question would be - why not instead pref-gate a mousedown/mouseup similar to the gecko privileged nsIDOMWindowUtils.sendMouseEvent? Is that crazy talk? Regardless it sounds a lot more challenging - maybe too challenging - so i'll have a go at the above first in any case.

[Manishearth]

We could do those, too. @jdm thoughts?

I would prefer having specific activation ones too, because there is some logic lodged between activation and mouse clicks that you may want to bypass.

[jdm]

We are almost at the point where we can write tests using webdriver that a) don't require adding gated, privileged APIs, b) can be run in multiple browsers, so I don't think that we should spend too much effort on these things right now.

[jdm]

Then again, if there are things we would like to test right now we should go ahead and do what's necessary for them. The webdriver stuff is gated on #12223 and then figuring out why the existing webdriver tests fail before starting to write more.

[Manishearth]

Oh, we are?

I was under the impression that webdriver was still quite far away.

Anyway, this might be nice to have independent of webdriver's existence, because while webdriver will let you simulate clicks, you can't directly deal with activation -- like I said, I'd like to isolate the activation logic too.

I was also thinking about having a DOM mocking framework that lets us unit test the DOM, with a window/script thread and mockable resource task. But let's wait for webdriver to happen before we look into that.

[sjmelia]

I do intend to work on this, just a little busy these last few weeks.

I'll implement manishearth's suggestion as fiddling with the interfaces exposed to JS does sound like fun, and if necessary I can always pick up another case to back it out in favour of, or complement it with; a webdriver test.

Would it be possible to isolate the activation behaviour with a unit test? I.e. in Rust. Of course there are a very complicated set of dependencies?

[Manishearth]

We'd have to initiate all the JS/DOM stuff. It's doable, but I'm not sure if we should be doing it 😄