[Calendar] The box around the 'today' / current day icon in the bottom left is offset from the number date, causing overlap.

VERIFIED FIXED in Firefox OS master


4 years ago
3 years ago


(Reporter: jmitchell, Assigned: dholbert)


(Depends on: 1 bug, {regression})

2.2 S9 (3apr)
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master verified)


(Whiteboard: [3.0-Daily-Testing])


(2 attachments, 2 obsolete attachments)



4 years ago
Created attachment 8578139 [details]

In the calendar app there is a icon in the bottom left corner. This icon usually looks like the page of a desk-calendar with the current date in the middle of it. Recently the box around the number has become offset

Repro Steps:
1) Update a Flame to 20150316010202
2) Launch Calendar

The today icon in the lower left corner does not appear correct

Expected: The date # will be centered in the calendar page image (the box around the number) 

Environmental Variables:
Device: Flame Master
Build ID: 20150316010202
Gaia: 4868c56c0a3b7a1e51d55b24457e44a7709ea1ae
Gecko: 436686833af0
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (Master)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Repro frequency: 4/4
See attached: screenshot

Comment 1

4 years ago
This issue does NOT occur in 2.2

Actual Results: The image / icon appears normal

Device: Flame 2.2 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150316002502
Gaia: a6b2d3f8478ec250beb49950fecbb8a16465ff6f
Gecko: 18619f8f6c5c
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 37.0 (Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regression
[Blocking Requested - why for this release]:
Regression of a core feature,

requesting a window.
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regressionwindow-wanted
QA Contact: ychung
Mozilla-inbound Regression Window:

Last Working Environmental Variables:
Device: Flame 3.0
BuildID: 20150313225615
Gaia: d4177902b04b8fedcb7df9a30ae6e9677e03d2d4
Gecko: 7d4292757e62
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

First Broken Environmental Variables:
Device: Flame 3.0
BuildID: 20150313230116
Gaia: d4177902b04b8fedcb7df9a30ae6e9677e03d2d4
Gecko: 6cd4d71818ee
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Last Working Gaia First Broken Gecko: Issue DOES reproduce 
Gaia: d4177902b04b8fedcb7df9a30ae6e9677e03d2d4
Gecko: 6cd4d71818ee

First Broken Gaia Last Working Gecko: Issue does NOT reproduce
Gaia: d4177902b04b8fedcb7df9a30ae6e9677e03d2d4
Gecko: 7d4292757e62


possibly caused by bug 1142686
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Daniel, can you take a look at this please? Looks like the cause is the landing for bug 1142686 so this might need to be backed out.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(dholbert)
Likely similar to bug 1128354. (i.e. a regression from the optimization in bug 1054010. In this case, only exposed when my patch in bug 1142686 made that regression actually apply in the cases it was intended to.)

It's also possible that the new behavior will become the specced behavior. Basically [if this is what I think it is], there's an implicit interdependence between a flex item and its children, in sizing behavior.  We previously got around that by reflowing eagerly (inefficiently) -- first sizing the item based on its children, and then reflowing the children with the knowledge of the item's size. But now we're a bit more efficient try to avoid that double-reflow, which means the children behave as if their parent has an indefinite size. (so e.g. percent heights may resolve to "auto" when they previously were honored).  Per bug 1128354 comment 5, I think the spec should perhaps be changed to match our new behavior, and at least one spec-editor (Tab) seems to agree with me, and I think Chrome's implementation effectively agrees with me.

So, it'd probably be best to fix (or work around) this issue in the gaia CSS. I'll take a look and offer some suggestions soon.
(In reply to Daniel Holbert [:dholbert] from comment #5)
> Likely similar to bug 1128354. (i.e. a regression from the optimization in
> bug 1054010. In this case, only exposed when my patch in bug 1142686 made
> that regression actually apply in the cases it was intended to.)

(er, freudian slip -- meant to say "when bug 1142686 made that *optimization* actually apply...")
Flags: needinfo?(dholbert)
Flags: needinfo?(dholbert)
[I was able to reproduce this in desktop Firefox, running with a gaia profile]

Hmm, this might be a distinct issue from bug 1128354.  It looks like the relevant thing that's causing trouble here is this rule in shared/style/icons.css:
 .gaia-icon {
   position: relative;

If I remove that (in devtools or via manually editing the CSS file), then the border ends up in the right place.  It doesn't look like the gaia-icon is actually being relatively positioned, so it's a bit unexpected that this would have an effect right now. Seems likely that we're missing a step in the optimized reflow path somewhere.
Flags: needinfo?(dholbert)
Depends on: 1144259
After some testcase-reducing, I filed bug 1144259 on what I believe to be the underlying Gecko bug here.  It's actually a long-standing bug in incremental layout, but we weren't hitting it here until recently because flexbox was reflowing overly-aggressively. (and bug 1144259's symptoms can be flushed out with extra reflows)

So - this isn't actually a bug in flex layout. It's a bug in abspos/relpos-handling, in block layout (which we're happening to hit here, while inside of a flex container).
(I spent a little time trying to find a quick CSS hackaround for this, but I haven't found one yet. It might be most efficient to just wait on the fix for bug 1144259.)
Actually, I guess comment 7 has a pretty-good hackaround for this.

I'm not sure what we're trying to achieve with the "position:relative" on the gaia-icon class there. It makes a bit more sense for block-level elements (I think), where we may actually want to absolutely-position the icon within the .gaia-icon element. But it makes less sense for inline-level elements.

Anyway -- it doesn't seem to have an effect in this case. I don't know what the fallout would be from removing it from the shared icons.css class [I assume *something* depends on it], so for this bug, I propose we just override it locally with "position:static".

I'll post a pull request to do that.
Created attachment 8580938 [details] [review]
pull request: Override "position:relative" on .icon-calendar-today span, to avoid hitting bug 1144259.
Created attachment 8580946 [details] [review]
[gaia] dholbert:patch-2 > mozilla-b2g:master
Created attachment 8580950 [details] [review]
pull request: Override "position:relative" on .icon-calendar-today span, to avoid hitting bug 1144259

[autolander apparently didn't like my first pull request due to my use of "Bug NNN:" instead of "Bug NNN -". I was advised in #gaia to just create a new pull request. Here it is.]

Tagging mmedeiros to review -- let me know if there's someone else I should tag here.

(I verified locally that this fixes the bug, using desktop Firefox w/ a debug gaia profile in responsive design mode.)
Assignee: nobody → dholbert
Attachment #8580946 - Attachment is obsolete: true
Attachment #8580950 - Flags: review?(mmedeiros)
Attachment #8580938 - Attachment is obsolete: true
I think something changed on Gecko lately that fixed this issue, I was not able to reproduce on latest build:

Gaia-Rev        9b6f3024e4d0e62dd057231f4b14abe1782932ab
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/e730012260a4
Build-ID        20150323010204
Version         39.0a1
Device-Name     flame
You're right -- this no longer reproduces, with latest gecko (e.g. desktop Firefox nightly running with w/ a gaia profile).

mozregression range:

--> Fixed (or really, worked around) by bug 1128354, which gives us a second reflow here, because there must be something percent-height involved here.

The underlying gecko issue (bug 1144259) still remains, but the second reflow lets us work around it.
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
Comment on attachment 8580950 [details] [review]
pull request: Override "position:relative" on .icon-calendar-today span, to avoid hitting bug 1144259

I'll close my pull request, since it's just for a workaround which it seems we no longer need.
Attachment #8580950 - Flags: review?(mmedeiros)
blocking-b2g: 3.0? → 3.0+
status-b2g-master: affected → fixed
This issue is verified fixed on the latest Nightly Flame 2.5 build.

Actual Results: The icon is correctly placed.

Environmental Variables:
Device: Flame 2.5 KK (319 MB) (Full Flash)
BuildID: 20150629010206
Gaia: 8a1e4ae522c121c5cacd39b20a5386ec9055db82
Gecko: eaf4f9b45117
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 41.0a1 (2.5) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
status-b2g-master: fixed → verified
Flags: needinfo?(ktucker)
Flags: needinfo?(ktucker)
status-b2g-v2.5: --- → verified
Target Milestone: --- → 2.2 S9 (3apr)
status-b2g-v2.5: verified → ---
You need to log in before you can comment on or make changes to this bug.