See screenshot attached. -- Samsung Galaxy SII (Android 2.3.4) & Nexus S (Android 4.0.3) Mozilla/5.0 (Android; Linux armv7l; rv:12.0a1) Gecko/20120105 Firefox/12.0a1 Fennec/12.0a1

Note - This also applies to m.facebook.com as well with the UA changed.

The key underlying issue is that -webkit-border-image is being used. -moz-border-image needs to be used by facebook.

Actually correct comment 2 - -border-image should be used.

Can we get a link to the offending CSS file? My quick scan of touch.facebook.com indicates that -moz-border-image does appear to be used in their CSS: http://static.ak.fbcdn.net/rsrc.php/v1/yA/r/pRPZDReheke.css

Note - comment 5 references m.facebook.com's css source.

Note comment 5 refers to m.facebook.com.

Strange... If I spoof Fennec Native on desktop, everything looks fine. If I spoof Android, I get the missing images. On my device with Fennec (no phony) I get the missing images as well.... I wonder if they're keying off of something else?

On desktop firefox, switched the UA to fennec native, got this css link for touch.facebook.com https://s-static.ak.fbcdn.net/rsrc.php/v1/yr/r/D4PKpv2U8lb.css. Looks like they dynamically are choosing what CSS files to use...

Note that for comment 9, moz-border-image is being used, same as what Jet said in comment 4.

I think this is a Fennec bug. border-image does not seem to work there? The first case here is what facebook is doing. Essentially: .jewel .flyout:after { border-image: url(...) 49 28 29 28; border-width: 49px 28px 29px; ... other stuff } But even if I simplify that down to just a div { border-image: url(dataurl); } it is not working in Fennec.

Wesley, you are right. This is definitely a problem on our end. Just checked on Firefox vs. Chrome.

Ahh, and according to dbaron this is because in nightly we've changed our parsing of border image to better match the spec (I was comparing release firefox and nightly fennec).

As a general note for future reference on facebook - They appear to be dynamically generating their CSS by the user agent to minimize dead code in CSS. Likely my guess to capture any additional issues will require utilizing the moz-specific CSS code for facebook.com. Switching the UA to capture the issues will not work.

I think the only fix needed here is for facebook to add border-style: solid; to these boxes. The spec has them default to border-style: none, which results in nothing being shown. Beyond that, I don't think there are any other compatibility things needed for the new syntax.

(In reply to Wesley Johnston (:wesj) from comment #15) > I think the only fix needed here is for facebook to add border-style: solid; > to these boxes. The spec has them default to border-style: none, which > results in nothing being shown. Beyond that, I don't think there are any > other compatibility things needed for the new syntax. In adding that CSS property, how would that affect other layout engines? Currently, this renders correctly on webkit.

Has anybody contacted Facebook about this?

Yes. They're working on it.

Given the most recent comments I understand this to be a Facebook specific issue. We won't block on site specific issues.

In disagreement, as bug 747123 does indicate that UA sniffing is part of a k9o user story. We need to discuss this to agree on what is and isn't a k9o blocker then, cause I don't think there is in general agreement on what we would or would not block on.

Update to comment 21 - This is a bug in relation to webkit-specific properties being used on a gecko site, as now, facebook does give us the right site, but with problems with webkit prefixes being used. Facebook is also the #2 site on alexa and a top app. This is related to mobile web compatibility k9o user story, so nominating for k9o.

Re-nominating for kilimanjaro. This isn't a webkit-specific issue, but this is related to bug 497995 and bug 713643. Same underlying issue as Lord of Ultima and Command and Conquer (border-style: solid being required).

Still can reproduce this bug on the current Nightly.

I can still reproduce on current Nightly. Chris - Was this issue passed on to Facebook? Any update on a timeline for a fix?

This is finally fixed.

Indeed it is!