Closed Bug 715515 Opened 12 years ago Closed 12 years ago

Facebook Touch & Optimized Mobile Facebook styling drop-downs for Friend Requests, Messages and Notifications is bad in Gecko

Categories

(Web Compatibility :: Site Reports, defect)

ARM
Android
defect
Not set
normal

Tracking

(blocking-kilimanjaro:+)

VERIFIED FIXED
blocking-kilimanjaro +

People

(Reporter: aaronmt, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [topapps][webkitcss])

Attachments

(2 files)

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
Depends on: 739832
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
Summary: Facebook Touch styling drop-downs for Friend Requests, Messages and Notifications is bad in Gecko → Facebook Touch & Optimized Mobile Facebook styling drop-downs for Friend Requests, Messages and Notifications is bad in Gecko
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.
Attached file Testcase
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.
Component: Evangelism → Layout: Images
Product: Fennec Native → Core
QA Contact: evangelism → layout.images
Whiteboard: [topapps]
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.
Component: Layout: Images → Evangelism
Product: Core → Fennec Native
QA Contact: layout.images → evangelism
Has anybody contacted Facebook about this?
Yes. They're working on it.
blocking-kilimanjaro: --- → ?
Given the most recent comments I understand this to be a Facebook specific issue. We won't block on site specific issues.
blocking-kilimanjaro: ? → -
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.
blocking-kilimanjaro: - → ?
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).
Depends on: 713643, 497995
No longer depends on: 739832
blocking-kilimanjaro: ? → +
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?
Component: Evangelism → Mobile
Product: Firefox for Android → Tech Evangelism
Version: Trunk → unspecified
This is finally fixed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Indeed it is!
Status: RESOLVED → VERIFIED
Whiteboard: [topapps] → [topapps][webkitcss]
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.