Closed
Bug 715515
Opened 13 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)
Tracking
(blocking-kilimanjaro:+)
VERIFIED
FIXED
blocking-kilimanjaro | + |
People
(Reporter: aaronmt, Unassigned)
References
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
Comment 1•13 years ago
|
||
Note - This also applies to m.facebook.com as well with the UA changed.
Comment 2•13 years ago
|
||
The key underlying issue is that -webkit-border-image is being used. -moz-border-image needs to be used by facebook.
Comment 4•13 years ago
|
||
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
Comment 5•13 years ago
|
||
Updated•13 years ago
|
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
Comment 8•13 years ago
|
||
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?
Comment 9•13 years ago
|
||
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...
Comment 10•13 years ago
|
||
Comment 11•13 years ago
|
||
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.
Comment 12•13 years ago
|
||
Wesley, you are right. This is definitely a problem on our end. Just checked on Firefox vs. Chrome.
Updated•13 years ago
|
Component: Evangelism → Layout: Images
Product: Fennec Native → Core
QA Contact: evangelism → layout.images
Updated•13 years ago
|
Whiteboard: [topapps]
Comment 13•13 years ago
|
||
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).
Comment 14•13 years ago
|
||
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.
Comment 15•13 years ago
|
||
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.
Comment 16•13 years ago
|
||
(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.
Updated•12 years ago
|
Component: Layout: Images → Evangelism
Product: Core → Fennec Native
QA Contact: layout.images → evangelism
Comment 18•12 years ago
|
||
Has anybody contacted Facebook about this?
Comment 19•12 years ago
|
||
Yes. They're working on it.
Updated•12 years ago
|
blocking-kilimanjaro: --- → ?
Comment 20•12 years ago
|
||
Given the most recent comments I understand this to be a Facebook specific issue. We won't block on site specific issues.
blocking-kilimanjaro: ? → -
Comment 21•12 years ago
|
||
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: - → ?
Comment 22•12 years ago
|
||
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.
Comment 23•12 years ago
|
||
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).
Updated•12 years ago
|
blocking-kilimanjaro: ? → +
Comment 26•12 years ago
|
||
Still can reproduce this bug on the current Nightly.
Comment 27•12 years ago
|
||
I can still reproduce on current Nightly.
Chris - Was this issue passed on to Facebook? Any update on a timeline for a fix?
Updated•12 years ago
|
Component: Evangelism → Mobile
Product: Firefox for Android → Tech Evangelism
Version: Trunk → unspecified
Comment 29•12 years ago
|
||
This is finally fixed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Whiteboard: [topapps] → [topapps][webkitcss]
Assignee | ||
Updated•6 years ago
|
Product: Tech Evangelism → Web Compatibility
Assignee | ||
Updated•7 months ago
|
Component: Mobile → Site Reports
You need to log in
before you can comment on or make changes to this bug.
Description
•