Closed Bug 995140 Opened 6 years ago Closed Last year

Google Calendar sends a lowfi version to Firefox OS


(Web Compatibility :: Mobile, defect, P5)

Gonk (Firefox OS)


(Not tracked)



(Reporter: cwiiis, Assigned: karlcow)


(Blocks 1 open bug, )


(Whiteboard: [country-all] [serversniff] [sitewait] [webkitcss])


(6 files)

Google delivers the low-fi version of Google Calendar to FirefoxOS. I get the nicer touch interface on Firefox for Android, which has some rendering issues (likely missing unprefixed/moz-prefixed bits), but works fine and is a massive step up from their basic interface.

I'd screenshot, but Google Calendar has chosen this moment to be unavailable :p

if you could test all corner cases, adding events, removing events, etc. in the calendar for Firefox Android and give a list of the glitches, that would be very useful! :)

And if the calendar is really working minor a few glitches, we could ask Google to send us this version.
Assignee: nobody → kdubost
Whiteboard: [country-all] [serversniff]
n?me, comment #1.
Flags: needinfo?(
Hmm ok. That doesn't really help.

Let me try…
On entering 

on Firefox OS 1.4, I get redirected to which is basically a very simple version of google calendar.
See Screenshot firefox-os-1.4.png

on Firefox Android (30), I get redirected to the same version than Firefox OS.

On Android Stock browser, I get a touch version at
See screenshot android-stock.png

If I copy/paste this into Firefox for Android, I get a version similar to the one on Android Browser.
See screenshot android-firefox-30-touch.png
Attached image firefox-os-1.4.png
Firefox OS 1.4 Google Calendar Screenshot
Attached image android-stock.png
Android Stock Browser Google Calendar Screenshot
Android Firefox Android Google Calendar Screenshot
In the Firefox Android version when manually requesting the enhanced version, we can notice the few common issues such as

* Missing Gradients
* Flexbox using the old WebKit Syntax instead of the new one.
Whiteboard: [country-all] [serversniff] → [country-all] [serversniff] [contactready]
I will contact Google about it but do not have your hopes too high. The official message is that anything which requires changes on the CSS is unlikely to be done.
Removing my needinfo, sounds like comment #7 provided the information necessary.
Flags: needinfo?(
Whiteboard: [country-all] [serversniff] [contactready] → [country-all] [serversniff] [contactready] [webkitcss]
Details for Google team. 
Testing So
When going through the CSS sent to Chrome Mobile, we can see things (more issues in the inline CSS. This is just an example) like:

	-webkit-transition:opacity 1000ms ease-out

	border:2px solid #fff;
	font:13px/17px sans-serif;
	margin:0 auto;
	padding:5px 3px;
	-webkit-box-shadow:0 0 8px rgba(0,0,0,0.7)


#og_head .og_a{

Most of these have their equivalents without -webkit- prefixes. For the flexbox properties, switching to the modern syntax would both ensure that the Web site is working on current and future versions of Chrome AND would make it compatible with more mobile devices.
Contacted Google.
Whiteboard: [country-all] [serversniff] [contactready] [webkitcss] → [country-all] [serversniff] [sitewait] [webkitcss]
News from Google.

> Thanks for the report. I've forwarded this along to the Calendar team and they're looking into it (internal issue # 15803694). I'll update you as I hear anything else.
Attached image google-calendar.jpg
This has not changed. We still receive a very lowfi version.

I wonder if we should put all the UA sniffing Google bugs on because usually the tier1 vs tier2/3 versions is shared by other browser vendors.
Hallvord, Daniel, 

This is the rendering of Google Calendar once unprefixed is activated globally. 
(It doesn't work yet completely with webkit pref, but that's normal, not everything has landed there).

As you may notice there is still a glitch with the day button. Looking at the code it is related to border-image.

``` css {
	-webkit-border-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAgAAAAhCAYAAADkrOp1AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAYFJREFUeNqEU7FOwzAQvXMuJSC1oqlKuoaZkakrGyti5i+Q+AZ+goERiR9hYEJiZKVIFaqgtJV9nO04SdO0TfQk5+75vedLgswM45vnDADuBOcCuy4vkmaOCE/ZqJ+nabcbxzFh0Zx8fQPFpG6z0eD0JEuPVUSglAJATyGaAxnm8WDY70WdBKIawd4RxUBa81EnSRTFHUdAu7tQQBUB+QW5B7BwvSKFEB2BpSCHAXsiZnQVV5dnKlauxAxlsyh7ggQFNKaSLgmmRvAeDUJQMAxKBAw0CRwIxmHdwCv7U4iCVUHYamFcyKZCGVLLbmhRMEHBD2jzFFCGlDruzYBtGbiaA2JbhkDQvonNSZraoGCnhbYpNxXsvkrBBd2mwMWgkHdYQAshhNQiz7hpYfYrQO1145YM8mf9afGIkBVg82XJnzDsH76vFr+z8FWtQTzU1UX+yKufj+V8NtVGh0/Dgd38mLsvb5PL+4fX68/pPF8sda/uguzHmwjOBKngoE74F2AAuSgRtQsg/JsAAAAASUVORK5CYII=') 4 2 5 4;
	border-width: 4px 2px 5px 4px;


``` css
.ci-btn-left {
	margin-right: -1px;
	padding-right: 7px;
	position: relative;
	-webkit-border-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAgAAAAhCAYAAADkrOp1AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAPNJREFUeNpi/P//P0PDvOdCDAwM0UCsDsQgNhywACUlGRkZmvxtBCzV5NiVuNiZOGGSd5/+ZGBhZWaMCrATsFWTYVP/BzTtx8+/cN2/f/9jYAEK6kiLMin9/P2XAR38/fefgeXvPwZ2hv+MrH8w5YEKGBiYGAgAFhABtBorAInjVwA3gXZWEK+AbDcQ7ch/tPMFoZAk6EiG/6OxCdPIxMLM+PvP3/+//0MF0DGTEB/z82dvft8HmYINM1nqcO8/ee3zsfvPf1z99ef/D3RrGIHZn/fJq9+uW459NHv36Y8oUBEnugIQzQHEOtCygR1ZAUCAAQDx3KURavzvFAAAAABJRU5ErkJggg==') 4 2 5 4;
	border-width: 4px 2px 5px 4px;

Though when I replace with the right border-image, I still don't get something working. There is another issue here.
Flags: needinfo?(hsteen)
Flags: needinfo?(dholbert)
And previous comment, I have forgotten to mention Chrome User Agent.
Karl: I think this is caused by stuff explained in - search for "the fill keyword must be used". There is a similar bug for GMail somewhere.
Flags: needinfo?(hsteen)
I'm not familiar with the evolution of border-image, but it looks like hallvors is right. Per dbaron's post that hallvors linked to:

  We're planning to continue to support -moz-border-image for now
  (but with the updated behavior [...]). [...] Opera & WebKit's
  prefixed implementation still follow the old rules.

So, our handling of -webkit-border-image as a pure alias may be slightly invalid, since it has some outdated bonus behavior in true WebKit browsers. Not sure at this point how problematic that will be for us, on sites that depend on -webkit-border-image.

For now, can we try to address this on Google Calendar with tech evang (come up with a working unprefixed expression & suggest that they add that after their prefixed version)?
Flags: needinfo?(dholbert)
(Actually, even adding the "fill" keyword that hallvors alluded to isn't quite sufficient -- we also need "border-style: solid" to be specified, or we else we don't render any border. This is correct, per spec, as noted in bug 1120072 comment 3. [and Chrome is nonconforming -- ].

With those two changes -- adding 'fill' after the url() expression and adding 'border-style: none' -- the styles in comment 14 look nice to me, when applied to an element locally.)
(In reply to Daniel Holbert [:dholbert] from comment #18)
> With those two changes -- adding 'fill' after the url() expression and
> adding 'border-style: none' -- the styles in comment 14 look nice to me,
> when applied to an element locally.)

er, meant to say:  "adding 'border-style: solid'" (not 'none')
I removed the -webkit- in Blink and replaced it by {
    border-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAgAAAAhCAYAAADkrOp1AAAAGXRF…8mLsvb5PL+4fX68/pPF8sda/uguzHmwjOBKngoE74F2AAuSgRtQsg/JsAAAAASUVORK5CYII=') fill 4 2 5 4;
    border-width: 4px 2px 5px 4px;
    border-style: solid;

And it fixed the button as you can see in the screenshot (left Firefox/Gecko, right Opera/Blink). The rest is not fixed on purpose but the issues are very similar. 

I wonder if we should add a new conversion in the unprefixing service adding the right keywords.

.foo {
	-webkit-border-image: url() 4 2 5 4;

convert to 

.foo {
	-webkit-border-image: url() 4 2 5 4;
        border-image: url() fill 4 2 5 4;
        border-style: solid;

I opened
I agree we (In reply to Daniel Holbert [:dholbert] from comment #17)
> For now, can we try to address this on Google Calendar with tech evang (come
> up with a working unprefixed expression & suggest that they add that after
> their prefixed version)?

That would be ideal.

I've filed for -webkit-border-image and pinged Jacob Rossi to see if someone from the Edge team can help out with some notes on how they implemented it -- you can see from the test page linked there that they're not doing a simple alias.
I think I will try to do the same exercise I have done for Gmail, but I should be careful to test every parts of it.
Google Calendar's mobile site has dropped usage of -webkit-border-image:
Thanks Alan!
I will need to test again everything.
Priority: -- → P5
Closing as we are not working on Firefox OS anymore.
Closed: Last year
Resolution: --- → WONTFIX
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.