Disable INTL_API on Android release build

RESOLVED FIXED

Status

()

enhancement
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: m_kato, Assigned: m_kato)

Tracking

({dev-doc-complete})

Firefox Tracking Flags

(Not tracked)

Details

Assignee

Description

2 years ago
- Even if test is failure, we turn off INTL_API on release build now.
- Re-implement DateTimeFormater for non-INTL_API build
- After re-implementing it, turn off INTL_API on Android/x86 only even if not released build (for test)
Assignee

Updated

2 years ago
Blocks: 1215247
does it mean Intl API won't be available on release build?
in that case the documentation should be updated.
Assignee

Comment 2

2 years ago
(In reply to Tooru Fujisawa [:arai] from comment #1)
> does it mean Intl API won't be available on release build?
> in that case the documentation should be updated.

Yes, this is current decision.  But it won't be final.
Assignee

Updated

2 years ago
Depends on: 1343744
Can you provide some timeline for this? (timeline for when we'll be able to release Android with ICU and get rid of the non-ICU codepaths)

I'm working on a lot of elements that rely on INTL_API like LocaleService (with language negotiation), OSPreferences, mozIntl, L10nRegistry.
Assignee

Updated

2 years ago
Depends on: 1343766
Assignee

Comment 4

2 years ago
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #3)
> Can you provide some timeline for this? (timeline for when we'll be able to
> release Android with ICU and get rid of the non-ICU codepaths)
> 
> I'm working on a lot of elements that rely on INTL_API like LocaleService
> (with language negotiation), OSPreferences, mozIntl, L10nRegistry.

:snorp, could you answer it?
Flags: needinfo?(snorp)
Do we leave untested-until-it-reaches-beta code path indefinitely? I don't think it works well.
We should either:
1. Stand-up Intl/non-Intl jobs in automation (like e10s/non-e10s), or
2. Disable Intl on Android completely.
Assignee

Comment 7

2 years ago
For test,

- I will add skip-if for some xpshell test such as test_localeCompare.js.
- mochitest doesn't run on android-x86, so even if android-x86's all build turns off INTL API, we don't cover all tests on android-api-15.  (Maybe, snorp or blassy misunderstands it)
- I will add skip code for mochitest's interface tests such as test_interfaces.html
- gtest doesn't run on all Android.  So we can ignore this
- Like comment #5, we need back out it. (for test_DownloadUtils.js)
I don't think there is a specific timeline for when we'll be able to ship ICU on Android. It will depend on the efforts to get the APK size down.
Flags: needinfo?(snorp)
I've tried disabling the Intl API on Nightly for testing purposes, but all I'm getting is a busted build:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=2526287a0ae6f91bf736c726d9f79d56c649e150

Is that to be expected because of bug 1343766, or is this something else that need reverting again?
Assignee

Comment 10

2 years ago
(In reply to Jan Henning [:JanH] from comment #9)
> I've tried disabling the Intl API on Nightly for testing purposes, but all
> I'm getting is a busted build:
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=2526287a0ae6f91bf736c726d9f79d56c649e150
> 
> Is that to be expected because of bug 1343766, or is this something else
> that need reverting again?

bug 1344596 and bug 1343766
Assignee

Updated

2 years ago
Depends on: 1346098
Assignee

Updated

2 years ago
Depends on: 1344596
Builds pass, but there are at least some xpcshell failures.
Assignee

Updated

2 years ago
Depends on: 1347431
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #8)
> I don't think there is a specific timeline for when we'll be able to ship
> ICU on Android. It will depend on the efforts to get the APK size down.

Is there some documented criterion for the APK size and some documented rationale for that criterion? Is there an ongoing effort to slim down the non-libxul parts of the APK?
Flags: needinfo?(snorp)
Assignee

Updated

2 years ago
Depends on: 1349879
Assignee

Updated

2 years ago
Depends on: 1349884
(In reply to Henri Sivonen (:hsivonen) from comment #13)
> (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #8)
> > I don't think there is a specific timeline for when we'll be able to ship
> > ICU on Android. It will depend on the efforts to get the APK size down.
> 
> Is there some documented criterion for the APK size and some documented
> rationale for that criterion? Is there an ongoing effort to slim down the
> non-libxul parts of the APK?

There may be some documented rationale somewhere, but AFAIK there is no target number. Only that "smaller is better". My understanding is that there are ongoing conversations right now with product/BD about this.
Flags: needinfo?(snorp)
One such effort is led by me in tracking bug 1347797. The bug itself is deceivingly calm, but look at the dependency tree.
I'll change the documentation listed in bug 1215247 comment #104 to say it's nightly-only.
updated:
  https://developer.mozilla.org/en-US/Firefox/Releases/54

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/localeCompare

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator/prototype
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator/supportedLocalesOf
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator/compare
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator/resolvedOptions

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/prototype
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/supportedLocalesOf
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/formatToParts
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/format
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/resolvedOptions

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/prototype
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/supportedLocalesOf
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/format
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/resolvedOptions

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/getCanonicalLocales
Assignee

Comment 18

2 years ago
all issues are closed and this is meta bug.  So I close this.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.