Closed Bug 1450656 Opened 7 years ago Closed 7 years ago

Text missing in preferences on Japanese macOS builds

Categories

(Core :: Internationalization, defect, P1)

Product:
Core
Component:
Internationalization
Version:
61 Branch
Platform:
Unspecified
macOS
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla61
Tracking Flags:
Tracking Status
firefox-esr60 61+ fixed
firefox59 --- unaffected
firefox60 blocking verified
firefox61 --- verified

People

(Reporter: zyouhousikaku, Assigned: zbraniecki)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(4 files, 1 obsolete file)

screen_capture.png
74.32 KB, image/png
Details
Screenshot - failed to reproduce on linux, using 64bit nightly ja
518.12 KB, image/png
Details
Bug 1450656 - Canonicalize ja-JP-mac to ja-JP-macos and use BCP47 version in Fluent.
59 bytes, text/x-review-board-request
jfkthame
: review+
jcristau
: approval-mozilla-beta-
jcristau
: approval-mozilla-esr60+
Details
workaround.diff
515 bytes, patch
jcristau
: approval-mozilla-beta+
Details | Diff | Splinter Review
Attached image screen_capture.png —
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180401100341 Steps to reproduce: Incorrect rendering of preference menu on macOS like attached picture. Does not render all of menu. so user cannot change settings with preference menu I have reset profile, but it is still incorrect. Expected results: Render all of menu
OS: Unspecified → Mac OS X
Summary: incorrect menu → incorrect menu rendering on mac os
Oops, User-Agent in my first post is wrong. I have posted about this bug from my another windows PC. This is why above user agent is does not corresponding to content of this issue.
Correct User Agent is Here: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0
Component: Untriaged → Menus
Can you go to about:support and copy the contents here? I'm curious if your machine is using an outdated graphics driver. Also, can you try flipping the "Use hardware acceleration when available" preference that is under the "Use recommended performance settings" area in about:preferences?
Flags: needinfo?(zyouhousikaku)
Reminder for myself to check this on a current build from moz-central
Flags: needinfo?(sfoster)
Component: Menus → Preferences
Summary: incorrect menu rendering on mac os → Parts of preferences UI not drawn on mac os
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #3) > Can you go to about:support and copy the contents here? I'm curious if your > machine is using an outdated graphics driver. Also, can you try flipping the > "Use hardware acceleration when available" preference that is under the "Use > recommended performance settings" area in about:preferences? I cannot change hardware acceleration setting because UI to change it does not drawn. Is there another way? Following are contents in about:support (Japanese version) (I using japanese version Nightly) アプリケーション基本情報 ------------ 名前: Firefox バージョン: 61.0a1 ビルド ID: 20180403100105 更新チャンネル: nightly ユーザーエージェント: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0 OS: Darwin 17.5.0 マルチプロセスウインドウ: 1/1 (デフォルトで有効) ウェブコンテンツプロセス: 4/4 Enterprise Policies: Inactive Google キー: あり Mozilla Location Service キー: あり セーフモード: false 過去 3 日分のクラッシュレポート ----------------- すべてのクラッシュレポート Nightly の機能 ----------------------------- 名前: Activity Stream バージョン: 2018.03.29.1163-6170061b ID: activity-stream@mozilla.org 名前: Application Update Service Helper バージョン: 2.0 ID: aushelper@mozilla.org 名前: Firefox Screenshots バージョン: 30.1.0 ID: screenshots@mozilla.org 名前: Follow-on Search Telemetry バージョン: 0.9.6 ID: followonsearch@mozilla.com 名前: Form Autofill バージョン: 1.0 ID: formautofill@mozilla.org 名前: Photon onboarding バージョン: 1.0 ID: onboarding@mozilla.org 名前: Pocket バージョン: 1.0.5 ID: firefox@getpocket.com 名前: Presentation バージョン: 1.0.0 ID: presentation@mozilla.org 名前: Web Compat バージョン: 1.1 ID: webcompat@mozilla.org 名前: WebCompat Reporter バージョン: 1.0.0 ID: webcompat-reporter@mozilla.org 拡張機能 ---- セキュリティソフトウェア ------------ 種類: 種類: 種類: グラフィック ------ 機能 画像処理: OpenGL 非同期パン / ズーム: ホイール入力有効; スクロールバーのドラッグ有効; キーボード有効; 自動スクロール有効 WebGL 1 ドライバーの WSI 情報: CGL WebGL 1 ドライバーのレンダラー: NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine WebGL 1 ドライバーのバージョン: 4.1 NVIDIA-10.30.25 355.11.10.10.30.120 WebGL 1 ドライバーの拡張: GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_shading_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_depth_bounds_test GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_mirror_clamp GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier WebGL 1 拡張: ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_frag_depth EXT_sRGB EXT_shader_texture_lod EXT_texture_filter_anisotropic EXT_disjoint_timer_query OES_element_index_uint OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object WEBGL_color_buffer_float WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context WebGL 2 ドライバーの WSI 情報: CGL WebGL 2 ドライバーのレンダラー: NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine WebGL 2 ドライバーのバージョン: 4.1 NVIDIA-10.30.25 355.11.10.10.30.120 WebGL 2 ドライバーの拡張: GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_shading_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_depth_bounds_test GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_mirror_clamp GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier WebGL 2 拡張: EXT_color_buffer_float EXT_texture_filter_anisotropic EXT_disjoint_timer_query OES_texture_float_linear WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context Uses Tiling: true メインスレッド外ペイント有効: true Off Main Thread Painting Worker Count: 3 GPU #1 使用中: はい ベンダー ID: 0x8086 デバイス ID: 0x0166 診断 AzureCanvasAccelerated: 1 AzureCanvasBackend: skia AzureContentBackend: skia AzureFallbackCanvasBackend: none TileHeight: 512 TileWidth: 512 決定ログ WEBRENDER: opt-in by default: WebRender is an opt-in feature メディア ---- 音声バックエンド: audiounit 最大チャンネル数: 2 優先サンプルレート: 44100 出力デバイス デバイス名: グループ 内蔵スピーカー: AppleHDAEngineOutput:1B,0,1,2:0 入力デバイス デバイス名: グループ 内蔵マイク: AppleHDAEngineInput:1B,0,1,0:1 ライン入力: AppleHDAEngineInput:1B,0,1,1:2 変更された重要な設定 ---------- accessibility.typeaheadfind.flashBar: 0 browser.cache.disk.capacity: 358400 browser.cache.disk.filesystem_reported: 1 browser.cache.disk.smart_size.first_run: false browser.places.smartBookmarksVersion: 8 browser.privatebrowsing.autostart: true browser.search.suggest.enabled: false browser.startup.homepage: https://www.google.co.jp browser.startup.homepage_override.buildID: 20180403100105 browser.startup.homepage_override.mstone: 61.0a1 browser.urlbar.suggest.history: false browser.urlbar.suggest.openpage: false browser.urlbar.timesBeforeHidingSuggestionsHint: 3 dom.forms.autocomplete.formautofill: true extensions.lastAppVersion: 61.0a1 font.internaluseonly.changed: true media.gmp-gmpopenh264.abi: x86_64-gcc3 media.gmp-gmpopenh264.lastUpdate: 1522585949 media.gmp-gmpopenh264.version: 1.7.1 media.gmp-manager.buildID: 20180403100105 media.gmp-manager.lastCheck: 1522756890 media.gmp-widevinecdm.abi: x86_64-gcc3 media.gmp-widevinecdm.lastUpdate: 1522585950 media.gmp-widevinecdm.version: 1.4.8.1008 media.gmp.storage.version.observed: 1 media.mediasource.webm.enabled: true network.cookie.prefsMigrated: true network.predictor.cleaned-up: true places.database.lastMaintenance: 1522589132 places.history.expiration.transient_current_max_pages: 104858 plugin.disable_full_page_plugin_for_types: application/pdf privacy.trackingprotection.enabled: true privacy.trackingprotection.introCount: 20 security.sandbox.content.tempDirSuffix: af32a5c7-fc58-9040-acd1-e089cb4cb9b4 services.sync.declinedEngines: services.sync.engine.addresses.available: true services.sync.engine.creditcards.available: true storage.vacuum.last.index: 1 storage.vacuum.last.places.sqlite: 1522589132 ロックされた重要な設定 ----------- Places データベース ------------- JavaScript ---------- インクリメンタル GC: true アクセシビリティ -------- 有効: false アクセシビリティの無効化: 0 ライブラリのバージョン ----------- NSPR 想定される最低バージョン: 4.19 使用中のバージョン: 4.19 NSS 想定される最低バージョン: 3.37 Beta 使用中のバージョン: 3.37 Beta NSSSMIME 想定される最低バージョン: 3.37 Beta 使用中のバージョン: 3.37 Beta NSSSSL 想定される最低バージョン: 3.37 Beta 使用中のバージョン: 3.37 Beta NSSUTIL 想定される最低バージョン: 3.37 Beta 使用中のバージョン: 3.37 Beta 実験的な機能 ------ サンドボックス ------- コンテンツプロセスのサンドボックスレベル: 3 効果的なコンテンツプロセスのサンドボックスレベル: 3 国際化とローカライズ ---------- アプリケーションの設定 要求されたロケール: ["ja-JP-mac","en-US"] 利用可能なロケール: ["ja-JP-mac","en-US"] アプリケーションのロケール: ["ja-JP-x-lvariant-mac","en-US"] 地域設定: ["ja-JP"] デフォルトロケール: "ja-JP-mac" オペレーティングシステム システムのロケール: ["ja-JP"] 地域設定: ["ja-JP"]
Flags: needinfo?(zyouhousikaku)
You can go to about:config and set 'layers.acceleration.disabled' pref to true.
Flags: needinfo?(zyouhousikaku)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #6) > You can go to about:config and set 'layers.acceleration.disabled' pref to > true. I tried change this pref, but it does not fix this issue.
I forgot clear needinfo request to me.
Flags: needinfo?(zyouhousikaku)
I think this might be a Graphics issue. Milan, can you help get some attention on this?
Component: Preferences → Graphics
Flags: needinfo?(milan)
Product: Firefox → Core
Brian, is there somebody in the Tokyo office that runs OS X and can try to reproduce this?
Flags: needinfo?(milan) → needinfo?(bbirtles)
Priority: -- → P3
Whiteboard: [gfx-noted]
Arai runs OS X and we also have a spare Mac in the office (set to English currently, though, I believe) if Sotaro wants to try next time he visits the office. Arai, can you try to reproduce this?
Flags: needinfo?(bbirtles) → needinfo?(arai.unmht)
Doesn't reproduce for me with the following configurations: * Nightly 61.0a1 (2018-04-08) (64-bit) + clean profile + macOS 10.12.6 Japanese environment on MBP 13-inch Early 2015 * Nightly 61.0a1 (2018-04-08) (64-bit) + clean profile + OS X 10.11.6 Japanese Environment on iMac 21.5-inch Late 2013 I don't have environment with macOS 10.13 right now. I'll check the office's laptop tomorrow.
I wonder if this might be related to bug 1451688 or one of the other issues linked to bug 1440753. If so, it may have been resolved after the latest re-landing of bug 1440753 a few days ago. KiYugadgeter, do you still see this problem with the latest version of Nightly?
Flags: needinfo?(zyouhousikaku)
I still see this problem despite I using latest nightly. My configuration: Firefox Nightly 61.0a1 (2018-04-09) (64-bit) + clean profile (I reset profile from about:support) + macOS 10.13.4 Japanese Environment on MacBook Pro 15inch Mid 2012
Flags: needinfo?(zyouhousikaku)
cancelling my need-info, looks like we need a japanese build to reproduce this. KiYugadgeter, would you be able to use mozregression [1] to help track down exactly when this broke? 1. https://mozilla.github.io/mozregression/
Flags: needinfo?(sfoster) → needinfo?(zyouhousikaku)
(In reply to Sam Foster [:sfoster] from comment #15) > cancelling my need-info, looks like we need a japanese build to reproduce > this. KiYugadgeter, would you be able to use mozregression [1] to help > track down exactly when this broke? > > 1. https://mozilla.github.io/mozregression/ I found out the mozregression wont use non english locales, so cancel that.
Flags: needinfo?(zyouhousikaku)
We can reproduce this on ja build from https://www.mozilla.org/en-US/firefox/nightly/all/
Status: UNCONFIRMED → NEW
Ever confirmed: true
I guess that preference is new localization framework, so I think that ja build is broken now.
Flags: needinfo?(arai.unmht)
Investigating
Flags: needinfo?(gandalf)
I downloaded ja build from https://www.mozilla.org/en-US/firefox/nightly/all/ as per comment 17 and was unable to reproduce on Linux, 64 bit. Is that platform specific?
Flags: needinfo?(gandalf) → needinfo?(m_kato)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #20) > Created attachment 8966455 [details] > Screenshot - failed to reproduce on linux, using 64bit nightly ja > > I downloaded ja build from > https://www.mozilla.org/en-US/firefox/nightly/all/ as per comment 17 and was > unable to reproduce on Linux, 64 bit. > > Is that platform specific? Maybe yes. I cannot reproduce this on Windows 10, but can reproduce on macOS 10.13. So, this occurs on ja-JP-mac only.
Flags: needinfo?(m_kato)
Ah, ok. Will investigate on Mac.
Flags: needinfo?(gandalf)
I'm 95% sure it is Fluent.
Component: Graphics → Internationalization
Priority: P3 → P1
Oh, but of course... 1) In Localization.jsm we retrieve the list of app locales *as lang tags* [0] 2) From those we create MessageContexts in [1] 3) And then Message context creates its Intl formatters in [2] That must work unless... well, unless (3) fails because it expects a correct BCP47 language tag and we supplied it `ja-JP-mac` in [0]. The reason we need LangTags in [0] is that L10nRegistry uses the same locale name to create MessageContext (where it definitely should be BCP47) and to load resources (where it must be LangTags). I really need to get this one-off out of our system (bug 1424953). For now, I'll start by shifting us to use BCP47 in [0] and special-case `ja-JP-x-lvariant-mac` in L10nRegistry. (also, MessageContext should also throw if locale passed to its constructor is not a well-formed BCP47 then). [0] https://searchfox.org/mozilla-central/source/intl/l10n/Localization.jsm#104 [1] https://searchfox.org/mozilla-central/source/intl/l10n/L10nRegistry.jsm#273 [2] https://searchfox.org/mozilla-central/source/intl/l10n/MessageContext.jsm#1841
Assignee: nobody → gandalf
Status: NEW → ASSIGNED
Flags: needinfo?(gandalf)
See Also: → 1424953
Jonathan - my logic here is that we separated out two classes of uses of `GetApplocales`: - ones that don't care about ja-JP-mac but care about BCP47 use `getAppLocalesAsBCP47` - ones that don't care about BCP47 but care about ja-JP-mac use `getAppLocalesAsLangTags` Fluent+L10nRegistry unfortunately is at the crossroads of those two caring for both, BCP47 and the name of the resource package we create. To be honest, I think we knew this duck tape won't hold for long. In this patch I don't touch `getAppLocalesAsLangTags` which continue to happily use `ja-JP-mac`. I affect callers of `getAppLocalesAsBCP47` which, except of Fluent, shouldn't care about the `-mac` scenario. This makes me feel rather ok making this change and not being worried about edge cases blowing in our face, but full disclosure, it's 11:35pm and my brain is fried.
This is broken in Beta too. And it's worrying: the change rode the train until mid cycle in Beta, without nobody noticing it? I expect localization teams to use Nightly for their daily browsing :-\ [Tracking Requested - why for this release]: Japanese preferences (general pane) is broken on macOS
status-firefox60: --- → affected
status-firefox61: --- → affected
tracking-firefox60: --- → ?
59 had 4 strings, but it's non affected by this bug.
status-firefox59: --- → unaffected
Comment on attachment 8966477 [details] Bug 1450656 - Canonicalize ja-JP-mac to ja-JP-macos and use BCP47 version in Fluent. https://reviewboard.mozilla.org/r/235164/#review240894 Seems reasonable (did you confirm with an actual build yet?)
Attachment #8966477 - Flags: review?(jfkthame) → review+
Summary: Parts of preferences UI not drawn on mac os → Text missing in preferences on Japanese macOS builds
This will unfortunately not work, because we also need to one-off in L10nRegistry to load ja-JP-mac paths. But I have a better patch that generally moves us to use `ja-JP-macos` internally while leaving `ja-JP-mac` for the callers of LangTags and for L10nRegistry path searching only.
Attachment #8966477 - Attachment is obsolete: true
This approach is a bit more broad, and swaps the "default" - it makes the BCP47 behavior the one we carry around, and makes "LangTags" what it is - as a quirky one-off for ja-JP-mac. With this patch, we convert any requested/packaged/default locale `ja-JP-mac` at runtime into `ja-JP-macos` and carry it around as such, converting back to `ja-JP-mac` only for `AppLocalesAsLangTags` and in L10nRegistry when looking up the path. This severely reduces the number of places which have the `if (ja-JP-mac)` case and fixes this bug as well (because now we negotiate correctly and Intl API doesn't crash).
Comment on attachment 8966863 [details] Bug 1450656 - Canonicalize ja-JP-mac to ja-JP-macos and use BCP47 version in Fluent. https://reviewboard.mozilla.org/r/235542/#review242156 OK, this seems reasonable. I think you can now optimize a couple of the AsBCP47 accessors, now that they are just returning our stored form. ::: intl/locale/LocaleService.cpp:732 (Diff revision 2) > - if (mAppLocales.IsEmpty()) { > - NegotiateAppLocales(mAppLocales); > + AutoTArray<nsCString, 32> locales; > + GetAppLocalesAsLangTags(locales); > - } I'm a bit sad that we now do an extra copy into a local (temporary) array, but I guess it's OK; I don't see a good way to avoid it without spreading the special-case code for macos around more places. ::: intl/locale/LocaleService.cpp:744 (Diff revision 2) > AutoTArray<nsCString, 32> locales; > GetAppLocalesAsBCP47(locales); > > *aCount = locales.Length(); > *aOutArray = CreateOutArray(locales); On the other hand, this method can now be optimized, can't it? You can replace it with the old version of Get...AsLangTags, avoiding the temporary array. ::: intl/locale/LocaleService.cpp:771 (Diff revision 2) > if (mAppLocales.IsEmpty()) { > NegotiateAppLocales(mAppLocales); > } > aRetVal = mAppLocales[0]; > > SanitizeForBCP47(aRetVal, false); And you can drop the Sanitize call in this method, as mAppLocales holds values that have already been sanitized.
Attachment #8966863 - Flags: review?(jfkthame) → review+
Pushed by zbraniecki@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c0a3b5bb44f5 Canonicalize ja-JP-mac to ja-JP-macos and use BCP47 version in Fluent. r=jfkthame
https://hg.mozilla.org/mozilla-central/rev/c0a3b5bb44f5
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox61: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Verified in 61.0a1 (2018-04-15) (64 ビット) @zibi Can you request uplift approval? I would do it, but I have no clue if the patch requires any change for beta.
Status: RESOLVED → VERIFIED
Flags: needinfo?(gandalf)
Comment on attachment 8966863 [details] Bug 1450656 - Canonicalize ja-JP-mac to ja-JP-macos and use BCP47 version in Fluent. Approval Request Comment [Feature/Bug causing the regression]: bug 1415730 [User impact if declined]: Preferences UI broken in Firefox 60 for ja-JP-mac users [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes [Needs manual test from QE? If yes, steps to reproduce]: Yes 1) Install Firefox Beta 2) Launch Preferences [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: Yes [Why is the change risky/not risky?]: The fix requires us to handle ja-JP-mac differently which may manifest itself in various ways around the code (font selection, telemetry reporting etc. all may start using `ja-JP-macos` locale rather than `ja-JP-mac`). The whole spectrum of how it may affect the browser is not possible to compile, but optimistically we expect nothing to change, and conservatively we expect there may be some minor changes in 60 which will result in suboptimal font selection or some telemetry changing for the ja-JP-mac locale. I'd recommend pretty comprehensive QA of the ja-JP-mac build with this patch. [String changes made/needed]: None
Flags: needinfo?(gandalf)
Attachment #8966863 - Flags: approval-mozilla-beta?
This looks terribly quirky.. so many special cases... is this really the minimum impact change we can make to fix preferences?
Flags: needinfo?(gandalf)
We discussed it on the release planning meeting. I'm cautiously advocating for uplift in order to minimize the friction between ESR and future releases and also because the patch is not just a fix for this problem - it's actually the right way to handle locales in Gecko :) RelMgmt is concerned about the regressions and we would like to verify the patch in nightly before we decide on the uplift. My understanding is that the scope of potential regressions is very specific to the callers of LocaleService::GetRequestedLocales which are now returning BCP47 rather than LangTags. - https://searchfox.org/mozilla-central/search?q=GetRequestedLocales&path= The scope here is mostly things like font guessing, telemetry (confirmed by Pike to work well) etc. and I believe that we need a native Japanese speaker to browse the Japanese Web to verify that there's no regression. :m_kato, :emk - can you help us here? The patch is in Nightly, so all we would really ask for is to take Nightly on MacOS (ja-JP-mac) and browse the Web checking the codepaths which traditionally may have use `ja-JP-mac` for negotiation and now may get `ja-JP-macos` instead. I hope we migrated all of that into our LocaleService::NegotiateLanguages which should make this change be safe.
Flags: needinfo?(m_kato)
Flags: needinfo?(VYV03354)
Daisuke uses Mac as main laptop, could you help this too?
Flags: needinfo?(m_kato) → needinfo?(dakatsuka)
Flags: needinfo?(m_kato)
Okay, I will use Nightly on MacOS (ja-JP-mac) as my default browser today. ( https://www.mozilla.org/en-US/firefox/nightly/all/?q=Japanese,%20%E6%97%A5%E6%9C%AC%E8%AA%9E , right? ) Then, will report.
(In reply to Daisuke Akatsuka (:daisuke) from comment #45) > Okay, I will use Nightly on MacOS (ja-JP-mac) as my default browser today. > ( > https://www.mozilla.org/en-US/firefox/nightly/all/?q=Japanese, > %20%E6%97%A5%E6%9C%AC%E8%AA%9E , right? ) > Then, will report. Yes, and thanks.
As far as I use it today, it was no problem.
Flags: needinfo?(dakatsuka)
Attached patch workaround.diff — — Splinter Review
Here's a workaround we discussed on the call yesterday. I don't like it, but it is more local. Your call Julien :)
Flags: needinfo?(gandalf)
Yesterday, I used ja-jp-mac version of Nightly, I couldn't find new issue to browse a lot of pages. It works well.
Flags: needinfo?(m_kato)
Comment on attachment 8968944 [details] [diff] [review] workaround.diff while this patch indeed doesn't look like something we want long term, it scares me a lot less than the other one at this stage, so I'll take this in 60.0b14 and then we can reconsider the other patch for 60.1esr
Attachment #8968944 - Flags: approval-mozilla-beta+
Flags: qe-verify+
Attachment #8966863 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
I used 60.0b14 today, then I found no problem happening. Thank you!
Flags: needinfo?(VYV03354)
I managed to reproduce the bug using an older version of Nightly (2018-04-02) on macOS 10.13 I verified the fix using latest Nightly 61.0a1 and beta 60.0b14. The bug is not reproducing anymore.
status-firefox60: fixed → verified
status-firefox61: fixed → verified
Flags: qe-verify+
We don't have a 61+ option yet for ESR60, but I believe we still want to land the full fix on it for the 60.1 release.
tracking-firefox-esr60: --- → ?
Zibi, want to request esr60 uplift for the initial patch here?
Flags: needinfo?(gandalf)
Would that mean we'd back out the workaround and land the full patch instead?
Comment on attachment 8966863 [details] Bug 1450656 - Canonicalize ja-JP-mac to ja-JP-macos and use BCP47 version in Fluent. [Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: This will lower the maintenance cost of LocaleService and locale management throughout the ESR60 release cycle. User impact if declined: None Fix Landed on Version: 61 Risk to taking this patch (and alternatives if risky): Low - the patch is well tested in 61 and 62. String or UUID changes made by this patch: None It will require backing out the workaround.
Flags: needinfo?(gandalf)
Attachment #8966863 - Flags: approval-mozilla-esr60?
Comment on attachment 8966863 [details] Bug 1450656 - Canonicalize ja-JP-mac to ja-JP-macos and use BCP47 version in Fluent. approved for 60.1esr along with a backout of b70d5eaa7921
Attachment #8966863 - Flags: approval-mozilla-esr60? → approval-mozilla-esr60+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: