Build Device - Unagi Hashes <project name="gaia" path="gaia" remote="b2g" revision="319123f39aacfc98387390e1f173035f1870bacd"/> <project name="releases-mozilla-aurora" path="gecko" remote="mozilla" revision="48017631bc649ce43791db461d3a549ec51a27e3"/> Steps (Scenarios) This happens intermittently on the month view. I've seen it happen in such cases: 1. Cold bootup of the calendar 2. Warm bootup of the calendar 3. Switching calendar views I've also seen this intermittently fail through my python automated test too. Expected: The month title should always be viewable on the month view. Actual: A squashed title is sometimes seen, which is not readable. Possible that this is a building blocks bug.
blocking-basecamp: --- → ?
OS: Windows 7 → Gonk (Firefox OS)
Hardware: x86_64 → ARM
blocking-basecamp: ? → -
Keywords: polish, steps-wanted
This is going to be hard to give attention unless we can get STR. Blocking- for now, please re-nom if we get good steps.
I just figured out the steps that can consistently reproduce this bug: 1. Launch the calendar app 2. Switch to the next month 3. Go back to the homescreen 4. Re-launch the calendar app Result - I get the smashed up text on the left side seen in the screenshot.
blocking-basecamp: - → ?
Oh and - this isn't a visual design issue, it's a bug. I wouldn't call smashing text polish either.
Keywords: polish, steps-wanted
Summary: Intermittent - month title in calendar is getting squashed to the left side, which is unreadable → Month title in calendar is getting squashed to the left side and is unreadable upon switching to a new month and leaving + resuming the calendar app
Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.
Target Milestone: --- → B2G C3 (12dec-1jan)
I found some interesting issue in this bug. If we set the title text align to left and set direction to rtl (right to left), then the title cropped by overflow won't update with size change. I use nightly to record a clip to demonstrate this issue: http://www.youtube.com/watch?v=x1hEeeN8GSc If we remove the direction style (text will be cropped from right) or text align style (title will be align to right), both will make the text content correct. It seems to be a platform issue but I'm not sure it's an important issue or not. Firefox browser could also reproduce this issue but chrome browser handles it correctly. Hi James, Not sure why you want to set title to rtl direction, maybe you think the time information at right side is more important then left. We can (1) just ignore the direction, (2) listen to the size changed event for updating the content (3) wait for the platform fixing. or maybe you have better idea in your mind?
Nice work Steve! Correct the left side is the past month and it seemed less relevant. There is another patch that makes this case much more unlikely to need text wrapping/clipping. (https://github.com/mozilla-b2g/gaia/pull/6851). I think its highly unlikely to get a platform patch for this in our timeframe but we should definitely file a bug on this odd behavior. For now its probably best to remove the direction bit but it seems like we could easily run into similar issues with our RTL efforts.
(In reply to James Lal [:lightsofapollo] from comment #8) > Nice work Steve! > > Correct the left side is the past month and it seemed less relevant. > Sorry that I'm not quite under stand what you mean. The current month view title would be: December 2012 (non-cropped) / ...mber 2012 (cropped) Do you want to change December to November and apply ltr direction? > > I think its highly unlikely to get a platform patch for this in our > timeframe but we should definitely file a bug on this odd behavior. For now > its probably best to remove the direction bit but it seems like we could > easily run into similar issues with our RTL efforts. Yes, although RTL language is not in the V1 scope, we still need to face this problem in the future because we use text align to left in css frequently(Maybe we can force everything align to right, but it still sounds problematic for layout anyway...).
Created attachment 689652 [details] Patch for removing the direction to avoid platform bug
Attachment #689652 - Flags: review?(jlal)
(In reply to Steve Chung from comment #10) > Created attachment 689652 [details] > Patch for removing the direction to avoid platform bug What specific platform bug is filed? I want to make sure there's a bug on file for this.
Comment on attachment 689652 [details] Patch for removing the direction to avoid platform bug Do you mind filing the follow up bug Steve? (for the platform fix)
Attachment #689652 - Flags: review?(jlal) → review+
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Hi all, I've filed the platform bug in core/layout: https://bugzilla.mozilla.org/show_bug.cgi?id=820278, thanks.
Verified on 12/16.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.