Closed Bug 915715 Opened 6 years ago Closed 6 years ago

dynamically changing pref to enable/disable CSS property does not work on B2G


(Core :: CSS Parsing and Computation, defect)

Gonk (Firefox OS)
Not set





(Reporter: jfkthame, Unassigned)



The new testcase in bug 798843 is supposed to check that the context-{fill,stroke,value} property values are supported only if gfx.font_rendering.opentype_svg.enabled is true; if it's false, these values should be treated as invalid.

To test both the 'enabled' and 'disabled' behavior, the testcase uses SpecialPowers to toggle the pref on and off. On desktop Firefox, this works as expected, but on B2G it appears to have no effect, and so the tests for the non-default state (disabled, since bug 915019 has switched the default to enabled) all fail:

6126 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_bug798843_pref.html | fill not settable to context-stroke none - got context-stroke none, expected
6127 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_bug798843_pref.html | stroke not settable to context-fill none - got context-fill none, expected
6128 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_bug798843_pref.html | fillOpacity not settable to context-stroke-opacity - got context-stroke-opacity, expected
6129 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_bug798843_pref.html | strokeOpacity not settable to context-fill-opacity - got context-fill-opacity, expected
6130 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_bug798843_pref.html | strokeDasharray not settable to context-value - got context-value, expected
6131 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_bug798843_pref.html | strokeDashoffset not settable to context-value - got context-value, expected
6132 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_bug798843_pref.html | strokeWidth not settable to context-value - got context-value, expected

For bug 798843, I propose to simply disable the new test on B2G. However, this appears to indicate some kind of problem with responding to dynamic pref changes.

Filing this under CSS for now, as that's where the test failure manifests, though I wonder if the underlying issue is with the Preferences module, perhaps?
Is pref setting simply async in b2g because it has to round-trip through the parent process?
Flags: needinfo?(jonas)
It turns out this is known/expected behavior, and the solution is to use SpecialPowers.PushPrefEnv() instead, as mentioned at [1].

Confirmed this works as expected for the testcase in bug 798843 which prompted me to file this. Closing as invalid; sorry for the noise.

Closed: 6 years ago
Flags: needinfo?(jonas)
Resolution: --- → INVALID
Though having a known-broken SpecialPowers API really isn't great.
You need to log in before you can comment on or make changes to this bug.