When the yellow "Loading" tab disappears, watch how the 1st and 5th message titles shift up by a pixel, but messages 2,3, and 4 don't. http://www.youtube.com/watch?v=25e-FGBa50U
It may help to switch the video to 720p and go full screen.
What steps do you take to have this shifting happen? I'm trying to reproduce.
nothing special, but it doesn't happen every time. It is very frequent for me, though. Mac OS 10.6.4.
Ok, but what steps should I be doing to even have a chance of seeing this? I'm not sure what I should try doing.
Ah. The best way to get the loading behavior is to click a label that you don't visit often on the left. This will get you a yellow "Loading" tab on the top, and the messages will populate. Sometimes, I also see this bug in the inbox after logging into GMail.
Probably a subpixel layout change is caused by the appearance/disappearance of the "Loading" notification, perhaps only given some combinations of font metrics.
The "Loading" box seems to be position: fixed, just judging by appearances, doesn't seem like hiding/showing it would affect the layout of the messages. Maybe when the "Loading" box disappears is when the page gets whatever info it needs from the server and updates the layout of the page based on that info and that causes a small change for some reason.
I filed a similar bug in https://bugzilla.mozilla.org/show_bug.cgi?id=522970, which no longer works on the demo site. I don't think this behavior will be blamed on the server: no other browsers do this.
I wasn't trying to imply that it was a server issue.
...just that the layout update we do based on the information we get from the server is when the bug shows up.
Different browsers do rounding differently; our way has advantages and disadvantages. This is one of the disadvantages. I don't think we should change our rounding strategy unless rounding rules for CSS are standardized. (Or, at the very least, we should see what the WebKit guys end up doing to fix the zooming issues they're having problems with.)
(In reply to comment #11) > Different browsers do rounding differently; our way has advantages and > disadvantages. This is one of the disadvantages. Every fifth line of GMail redrawing seems like a pretty big disadvantage. I don't know enough about our layout algorithm to judge whether this a bug or not. Are you implying that this bug is WONTFIX?
It's hard to know without a simplified testcase.
The way we do rounding is probably contributing to this bug, but we can probably still fix it once we figure out what's going on. I certainly don't have a problem with rounding vertical font metrics or CSS line-height to device pixels if that's necessary.
(In reply to comment #14) > The way we do rounding is probably contributing to this bug, but we can > probably still fix it once we figure out what's going on. I certainly don't > have a problem with rounding vertical font metrics or CSS line-height to device > pixels if that's necessary. We should probably be doing both of those anyway. We already do some of the former in gfxPangoFonts (although it makes us fail lots of Ahem font tests); I thought we had a bug on the latter, but I can't find it.
Poking at GMail, it looks like the message rows are table rows all getting their height from a rule on the .xY class 'height:3.25ex'. So we might need/want to round ex and em units to device pixels in the style system. We'd lose the algebraic properties (e.g. that N*(Kem) == (N*K)em) but that might be OK for those units.
blocking2.0: ? → final+
Maybe Boris can take this?
Assignee: nobody → bzbarsky
7 years ago
Priority: -- → P1
Is this a regression?
blocking2.0: final+ → -
The only thing related to rounding behavior that I could imagine having caused this is perhaps something related to font metrics being less round. But I'm also afraid of changing our rounding behavior at this point in the cycle.
2 years ago
Whiteboard: [platform-rel-Google] [platform-rel-Gmail]
platform-rel: ? → ---
You need to log in before you can comment on or make changes to this bug.