770045 - Google docs spreadsheets broken - selected cell misaligned, changes applied to wrong cell

Status: VERIFIED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Ed Morley [:emorley]]

Attachment: Screenshot

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0

1) Add-ons disabled
2) Open a Google Docs spreadsheet
3) Click on a few different cells/highlight several cells, compare cell outline with highlight outline.

Expected:
Highlighted outline is lined up with existing inactive cell outline. 

Actual:
Highlighted outline is misaligned (see screenshot) & other peculiarities with formatting not being applied to the correct cell etc. Extremely difficult to make desired changes to document; renders Google Docs virtually unusable.

Regression range:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8cc01c494f6a&tochange=eb8f9356376a

Comment 1

[Alice0775 White]

I have a different range:
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/eb8f9356376a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120630083850
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/a52d79ad75da
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120630090151
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=eb8f9356376a&tochange=a52d79ad75da

Suspected: Bug 248239

(In reply to Ed Morley [:edmorley] from comment #0)
> 
> Regression range:
> http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8cc01c494f6a&tochange=eb8f9356376a

Comment 2

[Ed Morley [:emorley]]

Ah you are correct, must have taken the wrong branch at the last bisect step.
Thank you :-)

Comment 3

[Tal Aloni]

Attachment: Browser specific CSS (Same Google Docs Cell)

You guys are relentless,
The other Google issue (770014) reminded me of that Seinfeld episode where Kramer widens the lanes, but this one is far less amusing.

As mentioned in 770014, and can be seen in the attached picture, based on user agent identifier, Google sends us (Firefox) the height including of the border, to work around bug 248239, while Chrome and (most) other browsers, get a CSS with the height excluding the border, as required by CSS 2.1. This affects javascript as well.

Once Google learn that Firefox 16 is committed to CSS 2.1 on this, they could (and would) easily resolve this.

I know this is annoying in the short term, but I strongly believe that's the only way forward, I'll try to contact the Google Docs team.

Comment 4

[Tal Aloni]

just to clarify, I meant relentless as "Continuing without pause or interruption".

Comment 5

[Ed Morley [:emorley]]

Ah makes sense, thank you :-)

Moving to Tech Evang since they just need to stop special-casing Firefox.

Comment 7

[(no longer active)]

Tal, would you mind providing me with a write-up of what your patch fixed and what Google should do to fix this?  We have an internal channel with Google which we can use to notify them about this problem.  I just want to make sure that I don't make a mistake on that email because I don't know the specifics of what your patch fixed.

Thanks!

Comment 8

[Tal Aloni]

Thanks Eshan,
This is what I emailed to them:

Hi Google Docs Team,
In the upcoming Firefox 16, a longstanding bug has been fixed,
Up until Firefox 16, Firefox violated the CSS standard and calculated height using the border-box method, instead of the content-box method.
 
This bug was fixed recently, and as of Firefox 16 there will be no need to workaround this bug.
At the moment, users of Firefox 16 builds receives a browser-specific CSS that assumes that the browser still mis-calculate table cell height, which cause Google Docs Spreadsheets to look bad (see attached pic).

it would be great to have this fixed (based on user agent identifier).
 
More info:
https://bugzilla.mozilla.org/show_bug.cgi?id=770045

Comment 9

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

I'm a little worried about asking people to do version-based detection, given that we might end up having to slip the change to a different version if there are remaining major problems.  Is there some other detection method we can come up with or suggest?

Comment 10

[Tal Aloni]

David,
All reliable detection methods I'm aware of are based user agent identifier line.

Web developers like myself are already used to browser and version-based detection.

If we MUST avoid detection of a specific version, we could add a variable to the user agent identifier (such as "content+box+height"),
However, this is extremely uncommon, and I would not recommend it.

My recommendation is to pick the future version number that will honor the CSS specs, and stick with it.
Note that most developers write their HTML in a way that works-around this issue, I was surprised Google was counting on us to violate the specs, but I think that's the exception rather than the rule,
also note that even if issues arises, in most cases the result will be a few extra pixels of height (like in Gmail), I don't believe there are more than a few web-applications that will misbehave like the Google Apps Spreadsheets.

You also have to remember that the developers will be very pleased to have this issue resolved.

regarding "remaining major problems", if you refer to bugs, than I'm here to do everything that's necessary if such problems arises, although my tests were comprehensive (including javascript tests), and it's unlikely there are any.

Comment 11

[(no longer active)]

(In reply to comment #9)
> I'm a little worried about asking people to do version-based detection, given
> that we might end up having to slip the change to a different version if there
> are remaining major problems.  Is there some other detection method we can come
> up with or suggest?

Can't they just measure the height of a table cell and compare it against what should be if this bug exists?  Or something to that effect?

Comment 12

[Tal Aloni]

(In reply to Ehsan Akhgari [:ehsan] from comment #11)
> Can't they just measure the height of a table cell and compare it against
> what should be if this bug exists?  Or something to that effect?
It's possible to use javascript and do what you're suggesting, but you can only do this on the client *after* you've already sent it the html / css.

Comment 15

[Gervase Markham [:gerv]]

(In reply to David Baron [:dbaron] from comment #9)
> I'm a little worried about asking people to do version-based detection,
> given that we might end up having to slip the change to a different version
> if there are remaining major problems.  

This is hardly a massive issue; once they've developed the fix which stops sending the workaround for Firefox >= X, it surely won't be too hard for them to tweak the value of X.

Gerv

Comment 16

[Nick Santos]

A fix for this on the Google side should go out early next week.

Comment 17

[Ed Morley [:emorley]]

Thanks Nick! :-)

Comment 18

[j.j.]

added Google demo page in URL field

Comment 19

[Will Roberts [:bws42]]

I believe Google has deployed their fix; spreadsheets look right to me again.

Comment 20

[Ed Morley [:emorley]]

Looks fine for me too now.

Comment 21

[j.j.]

Did someone test with previous version of Firefox? ESR 10? Seamonkey?

Comment 22

[j.j.]

Dis some testing, looks good.
(BTW, Opera 12 is slightly broken now, the blue outline is not wide enough)

Comment 23

[Armen [:armenzg]]

I don't see such fix. I still see this issue (Mac 10.7 and Win7).
17.0a1 (2012-07-17)

Comment 24

[Tal Aloni]

(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #23)
> 17.0a1 (2012-07-17)
I can confirm this is fixed for Firefox 16.
I can also confirm that this is NOT fixed for Firefox 17.

Google is doing version based detection, so there you have it.
Nick, Thanks for the quick fix for 16, could you include future releases as well?
Thanks!

Comment 25

[Nick Santos]

Haha, you jumped the gun. Google hasn't rolled the fix out to all machines. We staged it on a few machines yesterday, but took it down for unrelated reasons. I will ping the bug when it is rolled out for real.

Comment 26

[Nick Santos]

The fix should be on all servers now.

Comment 27

[(no longer active)]

Thanks!

Comment 28

[[e-mail] (:bhearsum)]

Looks good to me.

Comment 29

[Tal Aloni]

I can confirm all is well for Firefox 16, 17 and older.

Nick, Your assistance with going toward the standards is much appreciated!

Comment 30

[Armen [:armenzg]]

Thanks a lot!

Comment 31

[Paul Silaghi, QA [:pauly]]

Related issue - bug 791696.

Comment 32

[Michael]

I'm still getting either this bug or a very similar one, on Firefox 16 and 64-bit Linux.  On all spreadsheets, the cell numbering is visibly misaligned with the cell rows (cell numbers have larger height than the associated row) and as you go further down the spreadsheet, the misalignment grows.  Highlighting and selecting is also misaligned.  I have done shift-reload to try to reload CSS files, etc.  Using Chrome the spreadsheets are fine, no problems.  Is it possible that the fix wasn't correct for all browser user-agents?

Your User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0

Comment 33

[u279076]

Michael, I assume you are using the Ubuntu package version of Firefox. It's possible that Google's fix to their UA sniffing did not account for Firefox versions packaged with various distributions. However, this was a bug on their side. I'm not sure if there's anything we can do here. 

You can either file a new bug here and we can try to reach out to Google, or you can file a bug in Ubuntu's Launchpad. You might have more success with the latter. 

There's really not anything else we can do on *this* bug report.

Comment 34

[Michael]

Yeah, sorry.  I guess I was assuming that Google's people would still be reading this bug report, a possibly erroneous assumption.  I agree that it's not a Firefox bug but a Google bug.  I'll try to report it to Google.

Comment 35

[j.j.]

(In reply to Michael from comment #34)
> Yeah, sorry.  I guess I was assuming that Google's people would still be
> reading this bug report, 

Nick Santos (Google) is still CCed here.

> I agree that it's not a Firefox bug but a Google bug.

It would be an "Tech Evangelism" bug for Mozilla, like this one is.
Please try to verify the problem on different computers. If there is no response from Google here, follow comment 33 (try to contact Google and/or file a bug blocking this bug)

Comment 36

[Nick Santos]

Comment #32 complains about numbering misalignment, but i don't remember that being a symptom of the original bug report. Agreed that we can't really do anything else on this bug report.

Michael, the Google docs support forum is probably the most appropriate place to report this. Off the top of my head, things that have caused cell misalignment include:
- specific spreadsheet constructs that we did not expect
- browser extensions
- differences in zoom behavior between browsers
- differences in box models between browsers
- obscure firefox preferences in about:config

Comment 37

[Frank Skare]

> - specific spreadsheet constructs that we did not expect

it happens in all spreadsheets

> - browser extensions

it happens in fresh profiles

> - differences in zoom behavior between browsers

it happens with both Firefox and IE and it happens only using Zoom so High DPI users are the fools as usual, Firefox still has other High DPI issues

> - obscure firefox preferences in about:config

it happens in fresh profiles

Comment 38

[Michael]

As a note to file, this is what I sent to Google:

-------------
"Google spreadsheet does not properly handle a minimum font size on Firefox 16+.

Reproduce: install Firefox 16, open Google spreadsheet.  Observe the row numbers at left.  Open firefox preferences, set minimum font size to 12 or higher.  Observe row numbers become misaligned with the associated row.  Highlighting cells also becomes misaligned (scroll down the spreadsheet to observe maximum effect).

Expected behavior: with a large minimum font size, row numbers and information in cells should be larger, but remain aligned.  Selecting cells should remain aligned.

Perhaps not very many users have a minimum font size set, but for those that do, this error appears as "google spreadsheets are broken" and is hard to figure out, so IMHO you pretty much have to work around it and make sure your app works with it.  I don't think I observed this prior to Firefox 16; this might be a sort of subtle error exposed by your fix for this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=770045

So basically, I think that what happened is that the change to the CSS box model for Firefox 16 (as described in that bugzilla bug report) exposed a latent bug in how minimum font sizes are handled on Firefox."
-------------

If any Firefox users are experiencing something like this and finding this bug report via web search, I suggest you may be able to fix the problem by changing your minimum font size setting.  I just verified right now that with Firefox 18, setting a minimum font size of 12 or higher still causes Google spreadsheets to appear broken.  All Firefox users can work around this by setting minimum font size to 11 or less until Google and Mozilla figure it out.  Cheers!