Bug 1532651 Comment 23 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to alexander :surkov (:asurkov) from comment #20)

> replacing XUL:checkboxes on HTML:input in #privacy preferences shows some good generic wins [1]:
> os-x: -7.5%,
> linux: -3,3%,
> win: -4.7
> 
> I do see some low confidence wins in general (for all tests), but #privacy subtest shows -25%, whose tendency should be trustworthy.
> 
> :jaws, how do you feel about an idea to conver checkboxes to HTML?
> 
> https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=try&originalRevision=4f1fe36d5dd85489cd565f50e96bf207b89c2ce4&newProject=try&newRevision=f5d6041ff2c6725c3df741a77f572b6d9a0b4447&originalSignature=1659171&newSignature=1659171&framework=1

IMO, converting in-content prefs checkboxes to HTML shouldn't pose a lot of risk given that the JS code to handle HTML inputs has been there for a while now: https://searchfox.org/mozilla-central/source/toolkit/content/preferencesBindings.js#447 and https://searchfox.org/mozilla-central/source/toolkit/content/preferencesBindings.js#268 . The CSS has been there for a while too.

But because of Fluent, all the checkbox strings would need to change string IDs (see my comment on the phabricator revision), which makes it difficult to uplift.

Other than that, this would be my preferred solution.

> Brian also suggested to try to replace XUL checkbox CE content by HTML, if it gives any good results it's worth to check.

HTML-ifying the CE content seems more risky since this affects all the checkboxes, and not just the preference ones, but could avoid string ID changes. There's also not that much precedent of using HTML content in XUL CEs.

> The other idea I had was to drop the <image> from the checkbox markup and inherited attributes since it seems unused mostly. This might give us enough wins to get back to the status quo and would be very lightweight / upliftable.

Dropping the .checkbox-icon from the CE (and removing the surrounding .checkbox-label-box) could work, but this is actually used in about:preferences so those usages will need to be re-implemented (.checkbox-label::before could be used for that).
(In reply to alexander :surkov (:asurkov) from comment #20)

> replacing XUL:checkboxes on HTML:input in #privacy preferences shows some good generic wins [1]:
> os-x: -7.5%,
> linux: -3,3%,
> win: -4.7
> 
> I do see some low confidence wins in general (for all tests), but #privacy subtest shows -25%, whose tendency should be trustworthy.
> 
> :jaws, how do you feel about an idea to conver checkboxes to HTML?
> 
> https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=try&originalRevision=4f1fe36d5dd85489cd565f50e96bf207b89c2ce4&newProject=try&newRevision=f5d6041ff2c6725c3df741a77f572b6d9a0b4447&originalSignature=1659171&newSignature=1659171&framework=1

IMHO, converting in-content prefs checkboxes to HTML shouldn't pose a lot of risk given that the JS code to handle HTML inputs has been there for a while now: https://searchfox.org/mozilla-central/source/toolkit/content/preferencesBindings.js#447 and https://searchfox.org/mozilla-central/source/toolkit/content/preferencesBindings.js#268 . The CSS has been there for a while too.

But because of Fluent, all the checkbox strings would need to change string IDs (see my comment on the phabricator revision), which makes it difficult to uplift.

Other than that, this would be my preferred solution.

> Brian also suggested to try to replace XUL checkbox CE content by HTML, if it gives any good results it's worth to check.

HTML-ifying the CE content seems more risky since this affects all the checkboxes, and not just the preference ones, but could avoid string ID changes. There's also not that much precedent of using HTML content in XUL CEs.

> The other idea I had was to drop the <image> from the checkbox markup and inherited attributes since it seems unused mostly. This might give us enough wins to get back to the status quo and would be very lightweight / upliftable.

Dropping the .checkbox-icon from the CE (and removing the surrounding .checkbox-label-box) could work, but this is actually used in about:preferences so those usages will need to be re-implemented (.checkbox-label::before could be used for that).

Back to Bug 1532651 Comment 23