Android is confused/mistaken about XUL widget support: it ships XUL widget code but not CSS, and doesn't load any of it in geckoview
Categories
(GeckoView :: General, defect, P3)
Tracking
(Not tracked)
People
(Reporter: Gijs, Unassigned)
References
Details
One of the things I'm finding out the hard way in bug 1724718 is that Android is... confused... about how much XUL it still supports.
There are a number of crashtest/reftests that use <tree>
or <search-textbox>
or other XUL widgets. These currently run and pass on Android (though many others are disabled, cf. https://searchfox.org/mozilla-central/rev/8f08c21f093be1c1c42438697f8bca67af94fc77/layout/reftests/reftest.list#410-417 ).
XUL widgets (now really just custom elements with minor other sprinklings) live in toolkit/content/widgets/
and are shipped on Android (compare other ifndef MOZ_FENNEC
and ifndef ANDROID
elsewhere in the file). However, we avoid loading them in geckoview specifically, which means (AIUI) that they would not be usable and indeed are not used by either GeckoView itself or Fenix.
However, the custom elements load in reftests and crashtests. But none of the supporting CSS is there, so the right appearance
, display
values and default margins/paddings/borders etc. are not set.
I am already shaving a great many yaks in bug 1724718, so I'm not sure I'll tackle this immediately. But I think it'd be a good idea to clarify what we want here, and then be more thorough in enforcing whatever it is we do want. If we want these widgets to work, we'll need to ship a bunch more CSS and image files, and we should probably re-enable some of the tests that are currently disabled. If, as I suspect, we do not want that, and the less XUL on android, the better, we should probably broaden the condition in customElements.js
so that the non-browser bindings / custom elements never get loaded, and update the jar.mn file so they do not get shipped, either. We may also be able to unship certain bits of C++/Rust from Android copies of Gecko... That is liable to break Things, though I don't know exactly what beyond the aforementioned already-kinda-useless tests...
Agi, can you confirm/deny my suspicions here?
Comment 1•3 years ago
|
||
First of all, thanks for doing all this research Gijs, really appreciate it!
We don't use any of the XUL custom elements and I think (ideally) we should not ship any of the related code whenever feasible.
we should probably broaden the condition in customElements.js so that the non-browser bindings / custom elements never get loaded, and update the jar.mn file so they do not get shipped
so yes, this is what we want.
we should probably broaden the condition in customElements.js so that the non-browser bindings / custom elements never get loaded, and update the jar.mn file so they do not get shipped
I think that's OK if we cause some breakage as long as we don't land it too close to the Beta merge date.
Updated•3 years ago
|
Description
•