Open Bug 1725506 Opened 3 years ago Updated 2 years ago

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)

All
Android
defect

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?

Flags: needinfo?(agi)

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.

Flags: needinfo?(agi)
Severity: -- → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.