Closed Bug 987065 Opened 11 years ago Closed 11 years ago

[Email] HTML cookie cache logic may fail to re-localize if the language is changed while the app is closed: happens for new account card at least

Categories

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1034227

People

(Reporter: whsu, Unassigned)

References

Details

(Whiteboard: 1.3tarakorun1, g+)

Attachments

(1 file)

Attached file Email_Log_20140324
* Description: This bug happened on V1.3T email app. New account page cannot display correct language after language changes back to English. The new account page displays the previous language. Attach the demo video and log. - Demo video: https://dc1.safesync.com/LMtzcYMp/WP_20140324_007.mp4?a=RwlscjvLGeA - Log: Email_Log_20140324 * Precondition: - No existing email account * Reproduction steps: 1. Launch the setting app 2. Tap "Language" item 3. Change the language to "Français" 4. Launch the email app and check the displayed language 5. Using card view to close email app 6. Go back to settings app to change back language to "English" 7. Launch the email app and check the displayed language again * Expected result: 1. Step 4 displays French 2. Step 7 displays English * Actual result: 1. Step 7 displays French * Build info.:(Tarako Build -> V1.3T) - Gaia a4b3223fb2c2109cdde86f1d5595aa90f05e9a39 - Gecko 947861d9d32a313d3a0f5f480ea458c9e70baf26 - BuildID 20140319180709 - Version 28.0 Thanks!
Whiteboard: 1.3tarakorun1
Summary: [Email][V1.3T] [Email][V1.3T] New account page cannot display correct language after language changes back to English → [Email][V1.3T] New account page cannot display correct language after language changes back to English
Summary: [Email][V1.3T] New account page cannot display correct language after language changes back to English → [Email] HTML cookie cache logic may fail to re-localize if the language is changed while the app is closed: happens for new account card at least
See Also: → 855198
Whiteboard: 1.3tarakorun1 → 1.3tarakorun1, g+
I don't see this getting a v1.3T specific fix and we've fixed this on v2.1-targeted trunk in bug 1034227, so I'm duping forward to that, even though the underlying problems are fundamentally quite different. If someone can justify blocker status for this (seems edge-casey, and many activities will cause us to regenerate/ignore the cookie cache), it is appropriate to reopen this bug rather than doing something on the bugging I'm duping forward to.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: