Bugzilla

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #21)
> For some reason I missed this comment, thanks for working on this Boris.
> I probably wasn't specific in my request before. What I'd like is `withStartingStyle`, rather than `forStartingStyle` .

OK, I will rename the name of this argument. i.e. replace `forStartingStyle` with `withStartingStyle`.

> So if `false` it will work as it works now, and if `true`, it will return all the rules it returns at the moment, and eventually the starting style that applies to the element. Would that be possible?

OK. If `false`, everything keeps the same.
If `true` we return the starting style. If there is no rule inside `@starting-style`, we return the styles of this element instead, just like `false` case. (i.e. No matter where there are any rules inside `@starting-style`, it always returns the rules for this element.)

Note: I intentionally mentioned "if there is no rule inside `@starting-style`" because we early return in the function of computing starting style if there is no matched rule inside `@starting-style`, to avoid redundant rule matching and cascading. So we return the rules by the computed style of this element instead.

It seems I can pass these tree tests now with my patches, at least, after applying https://phabricator.services.mozilla.com/D209329:
devtools/client/inspector/computed/test/browser_computed_matched-selectors-order.js
devtools/client/inspector/rules/test/browser_rules_at_starting-style.js
devtools/client/inspector/rules/test/browser_rules_layer.js

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #21)
> For some reason I missed this comment, thanks for working on this Boris.
> I probably wasn't specific in my request before. What I'd like is `withStartingStyle`, rather than `forStartingStyle` .

OK, I will rename the name of this argument. i.e. replace `forStartingStyle` with `withStartingStyle`.

> So if `false` it will work as it works now, and if `true`, it will return all the rules it returns at the moment, and eventually the starting style that applies to the element. Would that be possible?

OK. If `false`, everything keeps the same.
If `true` we return the starting style. If there is no rule inside `@starting-style`, we return the styles of this element instead, just like `false` case. (i.e. No matter where there are any rules inside `@starting-style`, it always returns the rules for this element.)

Note: I intentionally mentioned "if there is no rule inside `@starting-style`" because we early return in the function of computing starting style if there is no matched rule inside `@starting-style`, to avoid redundant rule matching and cascading.

It seems I can pass these tree tests now with my patches, at least, after applying https://phabricator.services.mozilla.com/D209329:
devtools/client/inspector/computed/test/browser_computed_matched-selectors-order.js
devtools/client/inspector/rules/test/browser_rules_at_starting-style.js
devtools/client/inspector/rules/test/browser_rules_layer.js

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #21)
> For some reason I missed this comment, thanks for working on this Boris.
> I probably wasn't specific in my request before. What I'd like is `withStartingStyle`, rather than `forStartingStyle` .

OK, I will rename the name of this argument. i.e. replace `forStartingStyle` with `withStartingStyle`.

> So if `false` it will work as it works now, and if `true`, it will return all the rules it returns at the moment, and eventually the starting style that applies to the element. Would that be possible?

OK. If `false`, everything keeps the same.
If `true` we return the starting style. If there is no rule inside `@starting-style`, we return the styles of this element instead, just like `false` case. (i.e. No matter where there are any rules inside `@starting-style`, it always returns the rules for this element.)

Note: I intentionally mentioned "if there is no rule inside `@starting-style`" because we early return in the function of computing starting style if there is no matched rule inside `@starting-style`, to avoid redundant rule matching and cascading.

It seems I can pass these tree tests now with my patches, at least, after applying https://phabricator.services.mozilla.com/D209329:
devtools/client/inspector/computed/test/browser_computed_matched-selectors-order.js
devtools/client/inspector/rules/test/browser_rules_at_starting-style.js
devtools/client/inspector/rules/test/browser_rules_layer.js

The try looks OK for devtools tests (https://treeherder.mozilla.org/jobs?repo=try&revision=acbcada3608118b545cbf79722bf070a5ac23f3c&selectedTaskRun=c2RZ_y9OQw2TS5ZjhsXdfQ.1). (Note that there is one orange but I guess it is an intermittent.)