914252 - Google calendar tier1 header would not render in Firefox Android

Status: RESOLVED FIXED

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

Description

[Lawrence Mandel [:lmandel] (use needinfo)]

Attachment: googlecalendarcomparison.png

As shown in the attached screenshot comparison, the header for Google Calendar renders incorrectly in Firefox.

Comment 1

[Mike Taylor [:miketaylr]]

Hmm, I don't get that version of the Calendar. I'll upload a screenshot of the lo-fi one I get in Firefox for Android 23.0. Were you doing any spoofing?

But spoofing with the FxOS Tablet UA gets me to that same version (yay?) and I can verify the problem. There's an inline stylehsheet (will attach) that contains a ton of -webkit-border-image data URIs, and a few -webkit-border-radius styles all without an unprefixed or -moz- variant.

Comment 2

[Mike Taylor [:miketaylr]]

Attachment: google calendar inline css

Comment 3

[Mike Taylor [:miketaylr]]

Attachment: screenshot of google calendar

Comment 4

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Mike Taylor [:miketaylr] from comment #1)
> Hmm, I don't get that version of the Calendar. I'll upload a screenshot of
> the lo-fi one I get in Firefox for Android 23.0. Were you doing any spoofing?

Must have been as I now get the same lo-fi version shown in your screenshot.

Comment 5

[Hallvord R. M. Steen [:hallvors]]

So if we want the hi-fi experience, we have to ask them both to amend sniffing and CSS, I suppose.

Comment 6

[Hallvord R. M. Steen [:hallvors]]

Some details: Requesting google.com/calendar redirects through accounts.google.com/ServiceLogin to www.google.com/calendar/m which is the lo-fi version. All HTTP-based redirects and backend sniffing.

Comment 7

[alex_mayorga]

This bugs me on FirefoxOS as well =(

Is there a tag to add?

Comment 8

[Karl Dubost💡 :karlcow]

Contacted Alex today.

Comment 9

[Karl Dubost💡 :karlcow]

* On Firefox OS, I receive a low-fi version. Nothing fancy. Nothing seems broken per se.
* On Firefox for Android. Same.

We still do not get the hifi version. We have to see if they decided to just ignore Firefox for the shinier version.

Comment 10

[Karl Dubost💡 :karlcow]

The lowfi version is rendering correctly.
The version delivered to WebKit browsers contains webkit only CSS properties. The most notable issues are gradient and flexbox.

I will close it as WONTFIX given 

* the last discussions we had with Google
* AND that this is not the version we are actually receiving.

Comment 11

[Karl Dubost💡 :karlcow]

Still no progress on this.
iOS Safari and Opera Mobile, Firefox Android are receiving the same version than Chrome.
Firefox OS, IE Mobile are receiving the low-fi version too.

The version sent to Firefox Android is still a version without the gradient and the colors fixed.

Comment 12

[Karl Dubost💡 :karlcow]

The mobile version of Google Calendar with Firefox Android + version number + CSS Unprefixing services doesn't solve anything.

Firefox gets spinning wheels. A canvas image which is never stopping.


These are all the properties used without standard equivalents in the CSS.

    -webkit-border-image: url('data:image/png;base64,
    -webkit-border-radius: 2px;
    -webkit-box-align: baseline;
    -webkit-box-flex: 1
    -webkit-box-orient: horizontal;
    -webkit-box-pack: end
    -webkit-box-shadow: 2px 2px 2px #ccc
    -webkit-line-break: after-white-space
    -webkit-text-size-adjust: none;

Comment 13

[Karl Dubost💡 :karlcow]

The irony is that when we use an iPhone UA, we get a slightly better version. Still with issue, but just a tad working better.

Comment 14

[Karl Dubost💡 :karlcow]

In the version sent to Chrome Mobile.

Our friend innerText Bug 264412 is used a couple of times (6 times):


example:
        function kb(a) {
            var b = r[E]("style");
            b.type = "text/css";
            b.innerText = a;
            Ya[y](b)
        }

        function Ab() {
            if (S) {
                var a = L[0];
                a && db.innerText != a ? (db.innerText = a, ca(eb, I), fb[H].backgroundImage = I, jb(S, Ma), jb(O, La), w(gb[H], Fa), w(S[H], ta)) : a || (w(gb[H], ta), w(S[H], Fa))
            }
        };


The version sent to Chrome Mobile has also plenty of issues with -webkit- only properties. 

example: using

#og_head .og_a{
    display: -webkit-box;
    -webkit-box-orient: horizontal;
}

instead of
#og_head .og_a{
    display: -webkit-box;
    -webkit-box-orient: horizontal;
    display: flex;
    flex-direction: row;
}

some of the CSS properties are set up with JavaScript

        function fa(a, b) {
            return a.WebkitTransition = b
        }

or
            ta = "-webkit-box",

or 

            Ta = "webkitTransitionEnd",
            Ua = "webkitvisibilitychange",


or
            W[H].WebkitBoxFlex = J;


or 
                if (r.webkitVisibilityState == Oa) {

or 
    function na(a, b) {
        return a.WebkitTransform = b
    }
or 
                    h[B].WebkitBorderRadius = "8px";
                    h[B].WebkitBoxShadow = "0 0 8px rgba(0, 0, 0, 0.7)";
                    h[B].WebkitBackgroundSize = "100% 8px";
                    h[B].backgroundColor = "#b0c8ec";
                    h[B].background = "#cddcf3 -webkit-gradient(linear, left bottom, left top, " + c ? "from(#cddcf3), to(#b3caed)) no-repeat top" : "from(#b3caed), to(#cddcf3)) no-repeat bottom";
                    h[B].font = "13px/17px sans-serif";

or
    si[L].o = function() {
        this.b[B].WebkitTransition = "-webkit-transform 0.7s ease-out";
        na(this.b[B], "translate3d(0," + (tc("iPad") ? qd + 17 : qd - this.b[jb] + yd - 17) + "px,0)")
    };

etc.



All of these seems fixable. That would be an interesting exercise to see if a shim for the full script could make Google calendar working on Firefox Android. Everything is contained in one page only.

Once prettified and CSS standard properties added we got a 102,625 lines of code.

All the CSS are easily fixable. Nothing really funky. And I'm under the impression that JS code would not take that much to fix too.

Comment 15

[Karl Dubost💡 :karlcow]

Attachment: google-calendar.jpg

Current comparisons.

Comment 16

[Hallvord R. M. Steen [:hallvors]]

This:
            function ib(a) {
                var b = l[G]("style");
                b.type = "text/css";
                b.innerText = a;
                Wa[y](b)
            }

is exactly why the icons don't appear in the header: they use innerText to add the actual CSS source to a STYLE element. Change that to textContent (or 

b.innerText = b.textContent = a;

to handle all browsers you might care about ;) and the header looks fine.

I'll leap to the conclusion that the similar header on GMail Touch is also broken for the same reason.

Comment 17

[Karl Dubost💡 :karlcow]

On Firefox OS when adding an event we get an XML error message transition, then the page is displayed. 


On Firefox Android, I get the desktop site first, then I can request the mobile site. The markup received is more or less very similar to the one sent to Chrome on Android with two issues in the CSS:
* webkit border-image
* webkit flexbox


I will prepare a similar work of screen testing that I did for gmail this week. In the spirit of show don't tell to make it easier for Google to evaluate the list of fixes needed. 
https://bug1036987.bmoattachments.org/attachment.cgi?id=8688736

Comment 18

[Karl Dubost💡 :karlcow]

Attachment: gcal-fixed-css.png

The CSS served as inline (included in the HTML of the document) is currently 
~ 106,808 lines once prettified with the following format:


 .selector {
     property: value;
     property: value;
 }
 <SPACE>

It makes it harder to test the modifications in the current developer tools Style Editor. Modifying individual properties in the inspector is working through.

To note that on these 106,808 lines, 105,616 are used for @font-face declarations.
The remaining 1192 are for the element styling. Once the styling has been fixed the UI is quite similar to the ones of Chrome on Android.

(full analysis soon)

Comment 19

[Karl Dubost💡 :karlcow]

Attachment: gcal-issues-gecko.png

Issues and different screens for Firefox OS and Firefox Android compared to Google Calendar on Chrome.

Comment 20

[Karl Dubost💡 :karlcow]

Recontacted Google today with the graph and describing the issues.

Comment 21

[Karl Dubost💡 :karlcow]

Attachment: firefox-gecko-blink.png

So here we have 3 screenshots:

From left to right

1. Gecko (Desktop) + Chrome UA
2. Gecko (Desktop) + Chrome UA + layout.css.prefixes.webkit; true
3. Blink (Desktop) + Chrome UA


In 1. (known webkit-only issues)
  * Missing items in the top bar, 
  * day menu not on 1 line 

In 2. we can notice, two glitches. (to be tested on device)
  * The line after the calendar tab label is stopped.

<div style="height: 26px;" id="og_p">
  <canvas width="1" height="52" style="height: 26px; width: 123px;"></canvas>

  <div style="position: relative; height: 26px;">
    <canvas width="178" height="52" style="height: 26px; width: 89px;"></canvas>
    <div style="width: 64px; left: 12px;" class="og_m">Calendar</div>
  </div>

  <canvas style="height: 26px;" class="og_a" width="1" height="52"></canvas>
</div>

The missing line is the 3rd canvas. I thought it was because it has no set width in the style attribute like the first one, but the markup in Blink is 

<div id="og_p" style="height: 26px;">
  <canvas height="52" width="1" style="height: 26px; width: 123px;"></canvas>

  <div style="position: relative; height: 26px;">
    <canvas height="52" width="180" style="height: 26px; width: 90px;"></canvas>
    <div class="og_m" style="width: 64px; left: 13px;">Calendar</div>
  </div>

  <canvas height="52" width="1" class="og_a" style="height: 26px; -webkit-box-flex: 1;"></canvas>
</div>

When I had: 

  <canvas style="height: 26px; flex-grow: 1;" class="og_a" width="1" height="52"></canvas>

This is being fixed.


  * The more button is not aligned on the right side.
    As a result the touch is not happening at the right 
    place for closing once opened. 

Not sure about this one. I see a difference in the computed values for both environment. I will upload a screenshot.

Comment 22

[Karl Dubost💡 :karlcow]

Attachment: gecko-blink-computed-values.png

So in that screenshot we see the different computed value. flex-direction is not the same but it doesn't seem to be logical.

Maybe Daniel has an idea.

Comment 23

[Daniel Holbert [:dholbert]]

(In reply to Karl Dubost :karlcow from comment #21)
> In 2. we can notice, two glitches. (to be tested on device)
>   * The line after the calendar tab label is stopped.

My patch in bug 1241021 fixes this. (They must be setting -webkit-box-flex on the canvas here using something like miketaylr's sample-code in bug 1241021 comment 0.)

>   * The more button is not aligned on the right side.

This is bug 1231682 -- an ancestor of this "more" element (#og_q) has "-webkit-box-pack: justify", which we reject.  If I manually give this element "flex-direction: space-between" (which is what that value will map to after bug 1231682 is fixed), then the "more" button gets snapped to the right place.

Comment 24

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #23)
> This is bug 1231682 -- an ancestor of this "more" element (#og_q) has
> "-webkit-box-pack: justify", which we reject.  If I manually give this
> element "flex-direction: space-between"

Sorry, I meant "justify-content: space-between" (not flex-direction)

Comment 25

[Daniel Holbert [:dholbert]]

(In reply to Karl Dubost :karlcow from comment #22)
> Created attachment 8714624 [details]
> gecko-blink-computed-values.png
> 
> So in that screenshot we see the different computed value. flex-direction is
> not the same but it doesn't seem to be logical.

(I'm not clear what element you have focused here, or what's going on. Is this the 3rd <canvas>, with class="og_a", which is responsible for the line that's missing in current nightly? That <canvas> has computed "flex-direction" of "row" for me. If you're seeing something different, that maybe merits investigation, though perhaps on a separate bug since it doesn't seem to cause rendering problems and we don't want this bug to get too long.)

Comment 26

[Daniel Holbert [:dholbert]]

Attachment: screenshot with bug 1231682 fixed (-webkit-box-pack:justify)

Here's a screenshot of what this looks like now in Firefox Desktop build, with a mobile Chrome UA spoofed, with bug 1231682's patch applied. (not yet landed, pending review)

Comparing to the middle screenshot in attachment 8714623 [details], you can see that both issues noted in comment 23 are fixed.

Comment 27

[Mike Taylor [:miketaylr]]

Karl, is this still a valid issue?

Comment 28

[Karl Dubost💡 :karlcow]

Attachment: firefox-chrome-calendar.jpg

Without UA override, this is what Firefox Android is getting from Google for Calendar.

Firefox on the left
Chrome on the right

This happens after a redirection from
https://calendar.google.com/ + login.

to https://calendar.google.com/calendar/gp?hl=en-GB for Chrome
to https://calendar.google.com/calendar/m?pli=1 for Firefox.

That said if I'm already logged in and I type https://calendar.google.com/
I seem to be redirected to https://calendar.google.com/calendar/gp?hl=en-GB

Let's test this.
Fresh profile.

1. Login in first to accounts.google.com
2. entering https://calendar.google.com/

nope same thing, going to
https://calendar.google.com/calendar/m?pli=1

but if I enter a second time
https://calendar.google.com/
then I get the fancy version (minus the top toolbar)

Comment 29

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 30

[Raul Bucata]

It seems that the issue has been fixed since at the first access of the page, I am getting the same rich layout as in Chrome:

https://prnt.sc/-2bfd4akQ6IO

karl, can you confirm this, please? (the reporter seems to have the account disabled)

Tested with:

Browser / Version: Firefox Nightly 100.0a1 (2015869419 -🦎100.0a1-20220317092857🦎)
Operating System: Samsung A51 (Android 11) -1080 × 2400 pixels 20:9 aspect ratio (~405 ppi density)
Operating System: Google Pixel 3 (Android 12) -1080 x 2160 pixels, 18:9 ratio (~443 ppi density)

Comment 31

[Karl Dubost💡 :karlcow]

Confirmed.