This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
These tests import a module which is missing from the environment.
I think this might be the intent of the test case, but I am asking Ghislain to comment here. Please observe: <dependency type="feature" value="higherOrderFunctions" satisfied="false"/> This in affect switches off the HOF feature in the implementation so any call to require-feature on HOF should throw an error in the test case. However, I am still uncomfortable with this, I think we are over using the framework of the test suite somewhat. In our implementation we are not even running this test because the satisfied=false on the dependency.
(In reply to comment #1) > This in affect switches off the HOF feature in the implementation so any > call to require-feature on HOF should throw an error in the test case. I'm fairly sure that this isn't the expected behaviour. If the implementation can enable a feature in response to a require-feature, it is free to do so, and only raise an error if it can't.
Good catch, I added the module dependency, awaiting your confirmation that it works for you. I agree with Tim's comment 2, i.e., the WG made an explicit decision that it is okay for an implementation to activate a feature even if it had previously deactivated it following the dependency of false on that feature. It comes down to saying that a dependency of false does not mean that the feature must be "not supported" for the test to be run, but that it must be "not activated" by default for the test to be run. It is fine for an implementation that does support a feature to not run tests with a dependency of false on that feature, if it is unable to deactivate it, so I also agree with O'Neil's last sentence in comment 1. Does it make sense?
This makes sense. I confirm tests have been updated.