1056146 - Fix zoom tests in browser/base/content/test/general/ (using FullZoomHelper) to work in e10s

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Markus Stange [:mstange]]

This prevents browser_bug1015721.js from working in e10s mode and also other tests that use FullZoomHelper and are marked with "Bug 691614 - no e10s zoom support yet".

Comment 1

[:Gijs (he/him)]

Interestingly, browser_bug559991.js using FullZoomHelper.load (which relies on promiseTabLoadEvent) and it's not broken. I've used it in other e10s tests and it seems to be fine because of all the shimming we do these days. However, all the other tests in browser/base/content/test/general that will shortly be referencing this bug rather than bug 691614 are still broken when running them in e10s mode locally, so something else in FullZoomHelper is breaking them in e10s...

Comment 2

[Neil Deakin]

All of these seem to just have floating-point rounding issues (got 1.1 but received 1.100000023841858). Is it sufficient to just round these to a couple of decimal places when comparing?
 
The exception is browser_bug1015721.js which uses EventUtils.synthesizeWheel which doesn't work yet.

Comment 3

[Neil Deakin]

See comment 2.

Comment 4

[Drew Willcoxon :adw]

Rounding to a couple of decimal places seems OK, but am I understanding right that the rounding errors only happen in e10s?  That seems weird, doesn't it?

Comment 5

[Neil Deakin]

It is odd. I will look in more detail next week and see if I can determine where the difference is.

Comment 6

[Neil Deakin]

OK, so in single-process mode, we always retrieve markupDocumentViewer.fullZoom to get the zoom. This means we get the single-precision float value stored there (1.1 becomes 1.100000023841858)

In e10s though, we cache the zoom value in JS in remote-browser.xml::_fullZoom. JS stores numbers as doubles (1.1 becomes 1.10000000000000008881784197001E0). JS rounds these to 16 digits which becomes 1.1

So the values don't compare the same. So we should either:

1. change the tests to account for the rounding issues
2. change ZoomManager to always return rounded values in all cases.

I would think 2 would be better since I'd expect the zoom value to always correspond to a value in the toolkit.zoomManager.zoomValues preference.

Comment 7

[Drew Willcoxon :adw]

Interesting, that sounds fine to me.

Comment 8

[Neil Deakin]

Attachment: Patch

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/94238545f5c1

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/94238545f5c1