[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
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. :)
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.
I don't see this either.
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
(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.
(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.
(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)
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;"> </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.
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?
(In reply to Daniel Holbert [:dholbert] from comment #11) > Anthony, does this also fix the alignment issue on your machine? Yup.
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.
Karl, can you add this to your things to bring up with Google?
Google has been contacted. I will inform if/when we receive more news.
Sent a reminder today.
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.
(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.
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?)
I am still seeing this at the default zoom level on my retina Mac with Firefox 40 and 43.0a1.
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.)
The issue still exists. I'm hesitating to recontact Google on this one. They know it already.