Closed Bug 953240 Opened 11 years ago Closed 8 years ago

Text cut off on mobile Yahoo, with a wide iframe being ineffectively clamped by "max-width: 100%", several layers deep inside of a -moz-box

Categories

(Web Compatibility :: Site Reports, defect, P5)

Product:
Web Compatibility
Component:
Site Reports
Platform:
Other
Android
Type:
defect

Tracking

(platform-rel ?, fennec+)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
platform-rel --- ?
fennec + ---

People

(Reporter: blassey, Assigned: karlcow)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: testcase, Whiteboard: [country-all] [webkitcss] [flexbox] [platform-rel-Yahoo!])

Attachments

(2 files)

tmp_Screenshot_2013-12-27-02-35-51-1489738110.png
607.29 KB, image/png
Details
testcase 1
788 bytes, text/html
Details 
      No description provided.
dbaron, can we get an assignee?
tracking-fennec: ? → 29+
Flags: needinfo?(dbaron)
Keywords: regressionwindow-wanted
FWIW, I can reproduce this in Firefox release for Android, too, so it's not a recent regression.

(Are we sure it's a regression at all?)

In any case -- what's happening is the <iframes> are too wide to fit in the viewport, and they're stretching their container, all the way up to the <body>, or something like that. The iframes are sized like so, in HTML:
 <iframe ...  height="380" width="630"></iframe>
and the entire chain of parent blocks up to the <body> are auto-sized, so they end up shrinkwrapping the widest element, which is the <iframe>. However -- a few elements (including the <iframe>) have "max-width:100%", though, which the author is expecting to evaluate against the viewport, but that's failing to clamp for some reason.  That's what's causing the bug. In Chrome for android, the iframes are clamped to the viewport-width (and are pannable), so nothing overflows outside of the viewport.

Note also that the page has:
 <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"/>
which tells us the page is mobile-optimized and disables heuristics for making wide desktop content viewable on mobile.
Version: unspecified → Trunk
Attached file testcase 1 — 
This boils down to a rendering difference between -webkit-box and -moz-box. (which may be a fix-worthy bug in moz-box)

Reduced testcase attached, with a much-wider iframe so that you can easily reproduce this in a desktop browser. Chrome honors the max-width on the iframe and prevents the text from sticking off the screen; Firefox does not.
(In reply to Daniel Holbert [:dholbert] from comment #3)
> Chrome honors the max-width on the
> iframe and prevents the text from sticking off the screen; Firefox does not.

Sorry, I spoke a little too hastily / hand-wavishly there.

So, "max-width: 100%" on the iframe should resolve against the *containing block*, which in this case is the <div> just inside the moz-box (in testcase 1). That containing block doesn't have a specified width and is sized by shrinkwrapping its content. So the max-width can't be resolved and ends up having no effect, which I believe is correct.

The same is the case in e.g. these data URLs, with no -moz-box involved:
 data:text/html,<div style="display:inline-block"><iframe width=9000 style="max-width:100%25">
 data:text/html,<div style="float:left"><iframe width=9000 style="max-width:100%25">
(note: "%25" = urlencoded form of "%")

The "max-width: 100%" similarly has no effect there. (though, interestingly, it does have an effect there in Chrome... I think that's a bug?)

So I'm pretty sure what we're doing here, given the markup, is actually consistent and reasonable. (at least in the testcase, and I think in the original URL as well)

Now -- to work around it, I'd expect that Yahoo could just specify "max-width: 100%" on the chain of ancestors containing-blocks all the way up.  (This works in e.g. my data URL examples earlier in this comment.)  However, that doesn't work, because "max-width:100%" appears to be ineffective in clamping the size of the direct child of the -moz-box element. (This seems to be true in general, from local testing.)  I suspect that's due to a form of bug 681050.
Summary: Text cut off on mobile Yahoo → Text cut off on mobile Yahoo, with a wide iframe being ineffectively clamped by "max-width: 100%", several layers deep inside of a -moz-box
Wouldn't this site render as expected if they simply removed the -moz-box style?
(it seems to fix it for the testcase)
Keywords: regressionwindow-wanted → testcase
Priority: -- → P5
So, is this something we should fix in -moz-box or something where we should reach out to Yahoo about?
Flags: needinfo?(dholbert)
(In reply to Mats Palmgren (:mats) from comment #5)
> Wouldn't this site render as expected if they simply removed the -moz-box
> style?
> (it seems to fix it for the testcase)

It does, actually! Looks like the "display:block" works just fine here.

Specifically: if I add style="display: block" to <div id="yog-page"...> and <div id="yog-body"...> (the two (nested) -moz-box containers), the page renders correctly (i.e. identically to the way the unaltered page renders by Chrome on my Nexus 4).

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #6)
> So, is this something we should fix in -moz-box or something where we should
> reach out to Yahoo about?

I think we should reach out to Yahoo. To the extent that there's a Gecko bug here, it's bug 681050, but given that -moz-box is on the way out (and there's an easy workaround), I suspect it's unlikely we'll put resources into fixing bug 681050.
Flags: needinfo?(dholbert)
Component: Layout → Mobile
Product: Core → Tech Evangelism
This code fixes the issue on the testcase.

.ct-box {
   display:-webkit-box;
   display:-moz-box;
   display:flex;}

.ct-box {
   -webkit-box-orient:vertical;
   -moz-box-orient:vertical;
   flex-direction: column;}


I haven't found the specific place where it was used on the site. The webpage is including iframes which are themselves calling the iframe of the video. I also found occurences of -mox-box-sizing without any fallback.

The code of this site is interesting in many ways…

→ http GET http://sports.yahoo.com/blogs/nhl-puck-daddy/top-10-hockey-fights-2013-puck-daddy-review-205905009--nhl.html "User-Agent:$FANUA" | grep -i -C 5 -n "<root>"

437-
438-<div class="yom-remote"><div class="yom-loading" id="p_30345786_container"><!-- --></div></div>
439-<div id="yom-ad-LREC" class="yom-ad yom-ad-LREC" style="visibility: inherit;"><center><div id="yom-ad-LREC-iframe" class="yom-ad"><center>
440-<script>(function(){ var wrap = document.getElementById("yom-ad-LREC"); if (null == wrap) { wrap = document.getElementById("yom-ad-LREC-iframe") || {}; } var content = wrap.innerHTML || ""; if (content && content.substr(0, content.lastIndexOf("<script>")).indexOf("loc=LREC noad") !== -1) { wrap.style.display = "none"; } }())</script></center></div></center></div>
441-<iframe id="yom-ad-darla-callframe-mediaadsdarla" style="display:none;"></iframe>
442:<?xml version="1.0" encoding="utf-8"?><Root></Root>
443-</div>
444-
445-
446-<!-- END card -->
447-
Assignee: nobody → kdubost
Status: NEW → ASSIGNED
Whiteboard: [country-all] [webkitcss] [flexbox]
(In reply to Karl Dubost :karlcow from comment #8)
> This code fixes the issue on the testcase.

(per comment 7, "display: block" works as well, though I guess it doesn't fallback to -webkit-box for old browsers, if they actually want webkit-box there for some reason. I'm not sure why, because they don't seem to need it here.)

> I haven't found the specific place where it was used on the site.

I did -- see the two <div id="..."> in comment 7.
Depends on: 681050
Daniel, thanks.

Going a bit deeper for other potential issues.
There are instances of code with only vendors without the fallback prefixless. That will break in the future.

There are instances of code with only webkit. Such as -webkit-box-shadow.


For the flexbox issue:


.ct-box,.yui3-sidebar .ct-box-hd,.ct-box-bd,.ct-h-nav,.ct-b-nav,.ct-id,.ct-box-bd .ct-stack,.ct-row,.ct-f{display:-webkit-box;display:-moz-box;display:-ms-flexbox;display:box}

.ct-box-bd,.ct-id-name,.ct-b-nav,.ct-rl,.ct-l,.yui-sv-title,.ct-row .ct-row{-webkit-box-flex:1;-moz-box-flex:1;-ms-flex-order:1;box-flex:1}

.ct-box,.ct-box-bd .ct-stack,.ct-b-nav,.yui-sv-bd{-webkit-box-orient:vertical;-moz-box-orient:vertical;-ms-flex-direction:column;box-orient:vertical}

.ct-h-nav,.ct-row{-webkit-box-align:center;-moz-box-align:center}

.ct-b-nav{background:#fff;-webkit-box-flex:0;-moz-box-flex:0;-ms-flex-order:0;box-flex:0}


.ct-flex,.ct-stack,.ct-brand,.yui-sv-content{display:block;-webkit-box-flex:0;-moz-box-flex:0;-ms-box-order:0;box-flex:0}

.ct-poor{overflow:auto;height:auto;display:-webkit-box;display:-moz-box;display:-ms-flexbox;display:box;-webkit-box-orient:vertical;-moz-box-orient:vertical;-ms-flex-direction:column;box-orient:vertical}

.ct-poor .yui3-sidebar-content{display:-webkit-box;display:-moz-box;display:-ms-flexbox;display:box;height:auto;overflow-x:hidden}

.ct-poor .ct-box{display:block;display:-webkit-box;display:-moz-box;display:-ms-flexbox;display:box;height:auto}

.ct-submenu-height .ct-nested-nav{display:-webkit-box;display:-moz-box;display:-ms-flexbox;display:box}

.ct-b-nav,.ct-h-nav{-webkit-box-shadow:#1c1b1c -15px 0 15px -8px inset;border-right:1px solid #272627!important}

.shadow{-webkit-box-shadow:none!important;-moz-box-shadow:none;box-shadow:none!important}

.ct-row.ct-selected{background:#1b1b1b;-webkit-box-shadow:inset 3px 0 #2c5eb4}


The strategies used in the code seems to not be consistent. I guess edited by more than one person with a lot of legacy.
tracking-fennec: 29+ → +
I can look at addressing this on our end.  There is some legacy at play here, which I'm happy to hack through.

Is this only a problem for FF for Android?  I'm unable to reproduce on FF 28 for OSX.
It affects Firefox (Gecko) on all platforms, but only *for the content that Yahoo sends in response to the Firefox for Android user agent*.

You can make your desktop Firefox send the Fx-for-Android User Agent string by installing this extension:
 https://addons.mozilla.org/en-US/firefox/addon/user-agent-overrider/
That will put a button & dropdown-menu on your toolbar. Click the dropdown menu and pick "Android / Firefox 26". And then navigate to http://sports.yahoo.com/blogs/nhl-puck-daddy/top-10-hockey-fights-2013-puck-daddy-review-205905009--nhl.html and make your window skinny. You'll see that text gets cut off when the window is skinnier than the YouTube videos.
(In reply to Brian J. from comment #11)
> I can look at addressing this on our end.  There is some legacy at play
> here, which I'm happy to hack through.

Thanks for looking into this!

Per comment 5, if you want to be super-conservative, I think you *could* fix this by dropping the "display: -moz-box;" declaration, and leaving everything else in place. Then Gecko will render it as "display:block" (default for <div>) which seems to work just fine here, and non-Mozilla browsers won't be affected.)

(Or, per comment 8 / comment 9, you could also add "display:flex" which also should be backwards-compatible, though you'll want to make sure that works in both Blink & Gecko. Or, shaking things up a bit more, Comment 7 seems to indicate that you could drop all "-moz-box" / "-webkit-box" styles here without affecting the rendering.)
Re: comment 12 - thanks for the UA string.  I'll start testing this probably early next week.  As this is a common component Sports (among a number of other properties) are using, I'll have to see what impact any changes may have.  In any case - I should be able to get something acceptable done, tested and shipped within 2 weeks.  If I experience any oddities specific to FF in this regard, I'll chime back in here.

A big thank-you for filing this bug.  Feel free to let me know if you experience any other strange behavior on the Sports site and I'll be happy to file into our internal systems.
Thanks Brian--same goes to you, feel free to reach out with any questions or issues you might have. ^_^
FYI: Tracked at Yahoo! with id #6916878
Sorry for the delay - busy with NFL draft.

I've submitted the ticket to the correct property owner - Sports is using a common component within our pages.  With the submission, I proposed a simple patch to remove "height: auto !important" from ".yom-article .body iframe" which appears to be compounding any of the issues cited above.

As that common component is potentially used throughout other Y! properties, someone from that team will need to review / revise and accept that patch (or find an alternative fix).
From Yahoo! point of Contact

> The Sports team checked in a fix for the bug below 3 weeks ago at 2014-05-08.
Brian, 

thanks a lot for commenting and welcome here. 
In my testing I have still the same issues. Maybe it has not been deployed in production yet.
Flags: needinfo?(johnsonb)
I have tested today, and this seems to not be fixed on my Flame device at least.
Could someone else try too, so to see that's not just me. 

Oh also it might be interesting for Yahoo! Team. When accessing the same page
http://sports.yahoo.com/blogs/nhl-puck-daddy/top-10-hockey-fights-2013-puck-daddy-review-205905009--nhl.html
with an iPod Touch (iOS 6_1_6, AppleWebKit/536.26, Mobile/10B500, Safari/8536.25). The page starts to display well. Then it is flashing (apparently trying to load the iframe) and crash the browser. When restarting Safari, the browser crashes again. Can be reproduced 100% of time.
(In reply to Karl Dubost :karlcow from comment #20)
> I have tested today, and this seems to not be fixed on my Flame device at
> least.
> Could someone else try too, so to see that's not just me. 

Same here, with current Nightly on android.
The old patch addressed a declaration that was redundant.  Another patch has been submitted to the team that owns this in-page module to review and accept.  Apologize for the delay.
Flags: needinfo?(johnsonb)
platform-rel: --- → ?
Whiteboard: [country-all] [webkitcss] [flexbox] → [country-all] [webkitcss] [flexbox] [platform-rel-Yahoo!]
Since max-width has been fixed AND the effort of Yahoo! team this has been fixed.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Flags: needinfo?(dbaron)
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
Component: Mobile → Site Reports
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: