Closed
Bug 1089039
Opened 10 years ago
Closed 10 years ago
rendering problem with mlb.com Gameday
Categories
(Web Compatibility :: Site Reports, defect)
Tracking
(firefox33 unaffected, firefox34-, firefox35-, firefox36-)
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox33 | --- | unaffected |
firefox34 | - | --- |
firefox35 | - | --- |
firefox36 | - | --- |
People
(Reporter: alther, Unassigned)
References
Details
(Keywords: regression, testcase)
Attachments
(4 files)
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).
Reporter | ||
Comment 1•10 years ago
|
||
Here is what the problem area should be rendered as.
Reporter | ||
Comment 2•10 years ago
|
||
This problem is affecting Firefox 34 & 35. It rendered correctly in Firefox 31 (I haven't tried 32 or 33).
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.
Flags: needinfo?(alther)
Reporter | ||
Comment 4•10 years ago
|
||
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
Flags: needinfo?(alther)
Reporter | ||
Comment 5•10 years ago
|
||
Screenshot showing the Gameday icon so you can check it whenever you want (assuming the game is going on).
[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
Status: UNCONFIRMED → NEW
status-firefox33:
--- → unaffected
tracking-firefox34:
--- → ?
tracking-firefox35:
--- → ?
tracking-firefox36:
--- → ?
Component: Untriaged → Layout
Ever confirmed: true
Keywords: regression,
testcase
Product: Firefox → Core
Comment 9•10 years ago
|
||
STR with comment#7
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3ac1b309271d&tochange=aece7f9f944c
Triggered by: Bug 1032922
Blocks: 1032922
Comment 10•10 years ago
|
||
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
Comment 11•10 years ago
|
||
Not tracking this tech evangelism bug, will send this bug report to the site maintainers to let them know.
Comment 12•10 years ago
|
||
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 14•10 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(dholbert)
Resolution: --- → WORKSFORME
Assignee | ||
Updated•6 years ago
|
Product: Tech Evangelism → Web Compatibility
You need to log in
before you can comment on or make changes to this bug.
Description
•