1089039 - rendering problem with mlb.com Gameday

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect)

Description

[Rick Alther]

Attachment: mlb-gameday-34-render-problem.png

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

[Rick Alther]

Attachment: Proper rendering of the area in Firefox 31

Here is what the problem area should be rendered as.

Comment 2

[Rick Alther]

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

Comment 3

[Loic]

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
http://mlb.mlb.com/mlb/gameday/index.jsp?gid=2014_10_21_sfnmlb_kcamlb_1#gid=2014_10_24_kcamlb_sfnmlb_1&mode=wrap

But I don't see all the options "Box/Plays/Video/Field/Color" you have.

Comment 4

[Rick Alther]

This view is only visible during an ongoing game.  e.g. here is the link for tonight's game:
http://mlb.mlb.com/mlb/gameday/index.jsp?gid=2014_10_25_kcamlb_sfnmlb_1&mode=gameday

Comment 5

[Rick Alther]

Attachment: 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

[Loic]

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=18f408a5984e&tochange=83f519eb1a3a

supected bug: maybe bug 1042772

Comment 7

[Loic]

Attachment: 1089039.html (reduced testcase)

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

Comment 8

[Loic]

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

Comment 9

[Alice0775 White]

STR with comment#7
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3ac1b309271d&tochange=aece7f9f944c

Triggered by: Bug 1032922

Comment 10

[Daniel Holbert [:dholbert]]

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.)

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

Not tracking this tech evangelism bug, will send this bug report to the site maintainers to let them know.

Comment 12

[Daniel Holbert [:dholbert]]

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.

Comment 13

[Hallvord R. M. Steen [:hallvors]]

Daniel, status?

Comment 14

[Daniel Holbert [: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.