1052200 - Google calendar columns in week view are misaligned on Retina Mac & with full-page-zoom on other platforms, due to "wk-dummyth" element being a different size from the scrollbar

Status: RESOLVED FIXED

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

Description

[u279076]

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

I've recently noticed that columns in Google calendar are significantly misaligned in Firefox. Google Chrome and Apple Safari don't appear to display this issue. 

However, when investigating a regression window this seems to go back to Firefox 10.0. As such, I'm wondering if this is something server-side that has recently changed.

Here is the mozilla-central regression window for reference:
Last good revision: 2afc252b4d39 (2011-10-21)
First bad revision: e1a037c085d1 (2011-10-22)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2afc252b4d39&tochange=e1a037c085d1

Comment 1

[Daniel Holbert [:dholbert]]

Can you attach a screenshot (with any sensitive information removed)?  My Google calendar seems to be working correctly, so I wonder if you're just getting the short end of some A/B testing. :)

Comment 2

[u279076]

Attachment: Firefox.png

Screenshot displaying misalignment in Firefox.

Comment 3

[u279076]

Attachment: Safari.png

Screenshot showing proper alignment in Safari.

Comment 4

[u279076]

Florin, can you please check to see if you can reproduce this on any other platforms? I'm able to reproduce this here on Mac OS 10.9 on a 13" Retina Macbook Pro but Daniel can't reproduce on his Linux box. This may be platform/device specific.

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I don't see this either.

Comment 6

[Paul Silaghi, QA [:pauly]]

34.0a1 (2014-08-11)
I can see the problem on Ubuntu 14.04 and Win 7 too, but only if zooming the page (CTRL-'+').
This might be similar to bug 791696

Comment 7

[u279076]

(In reply to Paul Silaghi, QA [:pauly] from comment #6)
> 34.0a1 (2014-08-11)
> I can see the problem on Ubuntu 14.04 and Win 7 too, but only if zooming the
> page (CTRL-'+').
> This might be similar to bug 791696

I'm at zoom-level 0 on my Mac.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #7)
> I'm at zoom-level 0 on my Mac.

(Retina display is a little bit like having a permanent "full-page-zoom" in effect, since there are more device pixels per CSS pixel. So it's common for "retina-only" bugs to be visible on other platforms when they use full-page zoom.)

(In reply to Paul Silaghi, QA [:pauly] from comment #6)
> I can see the problem on Ubuntu 14.04 and Win 7 too, but only if zooming the
> page (CTRL-'+').

I can confirm that, on my Ubuntu box. (It helps if I make my window very wide, so that the days of the week don't just get squished when I zoom in.)

> This might be similar to bug 791696

I'm not sure -- at least for me, bug 791696's misalignment only ends up being off by 1-2px. Anthony's screenshot here looks much more severe.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #8)
> I'm not sure -- at least for me, bug 791696's misalignment only ends up
> being off by 1-2px. Anthony's screenshot here looks much more severe.

(Though actually, it does look like we're only off by 1-2px *per column* in this bug, and the more severe misalignment at the far right edge is just from the aggregate of those mistakes)

Comment 10

[Daniel Holbert [:dholbert]]

So, there are several tables involved here, but the relevant ones are:
 1) <table> w/ class="wk-weektop" containing the days' names & the allday events
 2) <table> w/ id="scrolltimedeventswk" containing the timed events

Table (2) has a scrollbar on the right side, which occupies some of the available width.

In order to keep table (1) aligned, due to its lack of a scrollbar, the page has this in table (1):
  <th class="wk-dummyth" rowspan="3" style="width: 12px;">&nbsp;</th>

This "dummyth" is what's responsible for the misalignment here, at least on my machine. When I zoom in, that element's 12px-width grows, but the scrollbar (in table (2)) that it's supposed to align with  does not grow.

Comment 11

[Daniel Holbert [:dholbert]]

When reproducing this bug, I can fix it locally by hiding the scrollbar and the "dummyth", by running the following code in my Web Console (Ctrl+Shift+K):

  $('.wk-scrolltimedevents').style.overflowY = "hidden"
  $('.wk-dummyth').style.display = "none"

The resulting UI is obviously not perfect -- no scrollbar, and no right border on the table (probably because google doesn't put one there, because they expect there to be a scrollbar). But the alignment issue becomes fixed.

Anthony, does this also fix the alignment issue on your machine?

Comment 12

[u279076]

(In reply to Daniel Holbert [:dholbert] from comment #11)
> Anthony, does this also fix the alignment issue on your machine?

Yup.

Comment 13

[Daniel Holbert [:dholbert]]

OK, thanks. That means the issue is that Google Calendar assumes their "wk-dummyth" element will be the exact width of the scrollbar, but it's not (depending on the platform and the full-page-zoomlevel).

For Google Chrome, Google Calendar works around this by styling the scrollbar, using the non-standard "::-webkit-scrollbar-thumb" pseudo-class, which lets them (a) specify exactly how large the scroll thumb is, and (b) implicitly makes the scrollbar get larger/smaller with full-page-zoom, since it's part of the page-content.  (If you don't use that pseudo-element, Chrome's scrollbars are fixed-size regardless of zoom level, just like Firefox's.)

That -webkit-scrollbar-thumb styling obviously doesn't work in non-Webkit browsers.  So I think this is a Tech Evang bug; we need to get this on the radar of someone on the Google Calendar team, I think.

Comment 14

[Mike Taylor [:miketaylr]]

Karl, can you add this to your things to bring up with Google?

Comment 15

[Karl Dubost💡 :karlcow]

Google has been contacted.
I will inform if/when we receive more news.

Comment 16

[Karl Dubost💡 :karlcow]

Sent a reminder today.

Comment 17

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

Daniel, is there a convenient way to make sure the size of the scroll bar adapts to zoom level in Gecko? I'm not sure if we have a fix we can recommend to Google here, I don't see any.

Comment 18

[Daniel Holbert [:dholbert]]

(In reply to Hallvord R. M. Steen [:hallvors] from comment #17)
> Daniel, is there a convenient way to make sure the size of the scroll bar
> adapts to zoom level in Gecko?

Not that I'm aware of. I don't think we make scrollbars stylable by content.

> I'm not sure if we have a fix we can
> recommend to Google here, I don't see any.

I've got one.

So, they're trying to align the columns of two different tables -- and the second table has a scrollbar, and the first does not.

The simplest way to solve this is just to put an *actual* scrollbar in the first table (but make it visibility:hidden so it won't be painted), instead of using a hardcoded-width table-cell (which is what they currently do).

I can fix this locally if I do the following:
 (1) Load Google Calendar at default zoomlevel, and then zoom in all the way (with Ctrl ++++++) to trigger the bug.
 (2) Find the element with class name "wk-dummyth" in devtools.
 (3) Give it "width: -moz-min-content" instead of the "width: N px" that it has in its style attribute (for some N).
 (4) Right-click that child and choose "Edit as HTML", and give it this child (replacing its current " " contents):
   <div style="overflow-y: scroll; visibility: hidden;"></div>
     ...and then click off to the left to confirm.

Comment 19

[Daniel Holbert [:dholbert]]

Also, worth noting -- right now, on my Linux system, the bug fixes itself on reload. I'm only seeing this if I *change* zoom level after loading.  I suspect this means they're dynamically measuring how wide the scrollbar actually is (in CSS pixels) at page-load-time, and then incorrectly assuming that it'll stay that way [but it doesn't if the user applies a full-page-zoom].

I expect this means this should be working correctly now with retina displays, since there's no dynamic zoom happening there -- it's just as if the user loaded the page with full-page-zoom already applied.  Is that correct? (ashughes, can you still repro on your retina mac?)

Comment 20

[u279076]

I am still seeing this at the default zoom level on my retina Mac with Firefox 40 and 43.0a1.

Comment 21

[Daniel Holbert [:dholbert]]

OK, thanks; I can actually still reproduce this, too, even after reload, at the zoomed-out-most (tiniest-content) zoomlevel. At most other zoom levels, the bug goes away after reload, but not at that one. So comment 19 isn't 100% accurate (and this makes your Retina behavior make more sense to me).

(I'm using this morning's Firefox Nightly 42 on Ubuntu 15.04, on a normal-resolution display.)

Comment 22

[Karl Dubost💡 :karlcow]

The issue still exists. I'm hesitating to recontact Google on this one. They know it already.

Comment 23

[Mike Taylor [:miketaylr]]

Hey Anthony, does this still repro in the new GCal design? Thanks.

Comment 24

[u279076]

While I can't see this issue on my current machine (Lenovo x260 running Fedora 27 and Firefox Nightly) I no longer have the Retina Mac I used in comment 20. Unless someone can reproduce this still I would suggest closing this bug report.

Comment 25

[Mike Taylor [:miketaylr]]

I don't see this on my mac w/ Retina mode enabled. Let's close.