If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

rendering problem with mlb.com Gameday



Tech Evangelism
3 years ago
3 years ago


(Reporter: Rick Alther, Unassigned)


({regression, testcase})

regression, testcase

Firefox Tracking Flags

(firefox33 unaffected, firefox34-, firefox35-, firefox36-)



(4 attachments)



3 years ago
Created attachment 8511450 [details]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141023111813

Steps to reproduce:

* Go to mlb.com and select the Gameday option for an ongoing game.
* The Box/Plays/Video/Field/Color box on the right of the screen does not render correctly (see screenshots).

Actual results:

The Box/Plays/Video/Field/Color box on the right of the screen does not render correctly.  The contents of the box appear to be overwritten in the left-most column while the other columns are not rendered where they should be and the center of the table is transparent. See screenshot

Expected results:

The box should render correctly (as it does in Firefox 31).

Comment 1

3 years ago
Created attachment 8511451 [details]
Proper rendering of the area in Firefox 31

Here is what the problem area should be rendered as.

Comment 2

3 years ago
This problem is affecting Firefox 34 & 35.  It rendered correctly in Firefox 31 (I haven't tried 32 or 33).

Comment 3

3 years ago
Sorry but this Gameday mode on this website is not obvious.
Could you post directly the URL to a page showing this issue, please.

I tried a gameday like

But I don't see all the options "Box/Plays/Video/Field/Color" you have.
Flags: needinfo?(alther)

Comment 4

3 years ago
This view is only visible during an ongoing game.  e.g. here is the link for tonight's game:
Flags: needinfo?(alther)

Comment 5

3 years ago
Created attachment 8511580 [details]
Screenshot showing Gameday icon

Screenshot showing the Gameday icon so you can check it whenever you want (assuming the game is going on).

Comment 6

3 years ago
[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

Regression range:

supected bug: maybe bug 1042772
status-firefox33: --- → unaffected
tracking-firefox34: --- → ?
tracking-firefox35: --- → ?
tracking-firefox36: --- → ?
Component: Untriaged → Layout
Ever confirmed: true
Keywords: regression, testcase
Product: Firefox → Core

Comment 7

3 years ago
Created attachment 8511620 [details]
1089039.html (reduced testcase)

I tried to reduce the testcase, maybe we can reduce more.

Comment 8

3 years ago
In FF33, you see the Firefox logo, not in FF34+.

Comment 9

3 years ago
STR with comment#7

Triggered by: Bug 1032922
Blocks: 1032922
Blocks: 1057162
No longer blocks: 1032922
Moving to Tech Evangelism. Based on the attached testcase, the site authors need to replace these lines:
>   flex: 1 0 auto;
>   width: 300%;

...with this:
>   flex: 1 0 300%;

Alternately, they can insert the line "flex: 1 0 main-size;" right after "flex: 1 0 auto;".

(Background: The flexbox spec changed what "auto" does in this context, and we're the only browser to have implemented it so far. "main-size" is the new keyword that means what "auto" used to mean here. And it really just means "use the value of the width property" [and 'width' has no other effects here], which is why the author really can just fold it all into one line, if they like.)
Component: Layout → Desktop
Product: Core → Tech Evangelism
Version: 34 Branch → Trunk
Not tracking this tech evangelism bug, will send this bug report to the site maintainers to let them know.
tracking-firefox34: ? → -
tracking-firefox35: ? → -
tracking-firefox36: ? → -
There's a chance that the CSSWG will resolve to change/revert the behavior in question this week (at TPAC, during flexbox discussions), so we should perhaps wait a few days before reaching out to site maintainers.
Daniel, status?
Flags: needinfo?(dholbert)
As suspected in comment 12, the "main-size" keyword rename was reverted in the spec, so we've removed it as well (bug 1093316), which means there's nothing to do here. Our behavior is effectively restored to a pre-regression-range state (from the range in comment 6).

I'm resolving this as WORKSFORME, since while this *was* a tech evang bug, no change is needed anymore.
Last Resolved: 3 years ago
Flags: needinfo?(dholbert)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.