Closed Bug 990767 Opened 9 years ago Closed 7 years ago

[B2G][Browser]zooming in/out in google maps does not display properly

Categories

(Web Compatibility :: Mobile, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v1.3 affected, b2g-v1.4 affected)

RESOLVED WORKSFORME
Tracking Status
b2g-v1.3 --- affected
b2g-v1.4 --- affected

People

(Reporter: rkuhlman, Assigned: karlcow)

References

()

Details

(Keywords: regression, Whiteboard: [country-all] [contactready] [serversniff])

Attachments

(1 file)

Attached file gMapZooming.txt
The zoom in/out feature of maps.google.com does not display properly. When zooming in, the screen zooms in on the upper right corner of the screen instead of zooming on the area between the users fingers. After releasing the screen, maps autopans to the area pinched by the user. Zooming out displays a similar effect.

Repro Steps:
1) Updated Buri to BuildID: 20140401000202
2) Launch Browser app.
3) Navigate to "maps.google.com".
4) Attempt to zoom in/out on the map.

Actual:
Screen zoom is focused on the upper right corner of the screen, then pans to the area indicated by the user.

Expected:
Screen zoom focuses on the area indicated by the user.

Environmental Variables:
Device: Buri v1.4 Moz RIL
BuildID: 20140401000202
Gaia: 216cc2e5c8692ba71aa78a9f27e84e9da27952b8
Gecko: 9223243c65a2
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Notes:

Repro frequency: 100%
See attached: video, logcat
Does this reproduce on 1.3?
Component: Gaia::Browser → General
Keywords: qawanted
QA Contact: jschmitt
QA Contact: jschmitt → demerick
This issue reproduces on Buri 1.3 MOZ RIL

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140401004003
Gaia: 24f562fce468fc948ac9e6185e002c23350cb9ee
Gecko: 0adf24a785f2
Version: 28.0
Firmware Version: v1.2-device.cfg

Screen zoom is focused on a different part of the screen before it pans to the area indicated by the user.
Keywords: qawanted
What happens on 1.1?
Keywords: qawanted
This issue does not reproduce on Buri 1.1 MOZ RIL.

1.1 Environmental Variables:
Device: Buri 1.1 MOZ
BuildID: 20140331041208
Gaia: 44a2ddf63373f8e95c784faf4ed4d60081699c61
Gecko: 170d87349060
Version: 18.0
Firmware Version: v1.2-device.cfg

Screen zoom focuses on the area indicated by the user.
Keywords: qawanted
QA Contact: demerick
Seems like this is a hit target problem with pinch to zoom. I can reproduce on 1.3 Buri.
blocking-b2g: --- → 1.3?
Component: General → Panning and Zooming
Product: Firefox OS → Core
Version: unspecified → 28 Branch
QA Contact: jharvey
Blocking since Google maps is a premier website, NI: milan to get his input here. We would need a regression window here. QA says this is specific to google maps.
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(milan)
Note: This regression window is before we had tinderbox builds available, this window was done with nightly builds.

Last Working
1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20131022040242
Gaia: 50f544a7530c266aab9bbc9a893e00e15d34c02f
Gecko: 177bf37a49f5
Version: 27.0a1
Firmware Version: v1.2-device.cfg

First Broken
1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20131023040203
Gaia: 6d23c2f9153d0e1d17679cb9c317e75a0ee9a490
Gecko: 21d97baadc05
Version: 27.0a1
Firmware Version: v1.2-device.cfg

First Broken Gecko Last Working Gaia: Issue reproduces
Gaia: 50f544a7530c266aab9bbc9a893e00e15d34c02f
Gecko: 21d97baadc05

Last Working Gecko First Broken Gaia: This issue does NOT reproduce
Gaia: 6d23c2f9153d0e1d17679cb9c317e75a0ee9a490
Gecko: 177bf37a49f5

Gecko pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=177bf37a49f5&tochange=21d97baadc05
blocking-b2g: 1.3+ → 1.3?
blocking-b2g: 1.3? → 1.3+
Does this reproduce with APZC disabled?
Keywords: qawanted
I tested this with the latest 1.5 build with APZ disabled and it reproduces.

The First Broken build in comment 8 does not have APZ as an option in settings. 

1.5 Environmental Variables:
Device: Buri 1.5 MOZ
BuildID: 20140403040201
Gaia: 0e974ff33ba47f3d1e59df1e0ad534f1bbe3ef8a
Gecko: 91be2828f17e
Version: 31.0a1
Firmware Version: v1.2-device.cfg
Keywords: qawanted
Note that disabling APZ via the developer menu doesn't affect browser content - APZ will still be enabled there. However google maps does its own touch event handling and zooming so this is more likely to be a bad input event problem or an evangelism issue than a zooming bug in the APZ.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11)
> Note that disabling APZ via the developer menu doesn't affect browser
> content - APZ will still be enabled there. However google maps does its own
> touch event handling and zooming so this is more likely to be a bad input
> event problem or an evangelism issue than a zooming bug in the APZ.

Then why is this working fine on 1.1?
That would require investigation to determine.
I imagine it'll be difficult for anybody else to be convinced to investigate :)
Assignee: nobody → bugmail.mozilla
Flags: needinfo?(milan)
Actually, I don't think this is pan&zoom, and is probably tech-evangelism.  Using the +/- buttons on the Google Maps gives us the same bad behavior - it zooms based on the corner, then resets the item into the middle. That can't possibly be our code.
Assignee: bugmail.mozilla → nobody
Flags: needinfo?(jsmith)
"couldn't possibly" is probably an overstatement above :)
(In reply to Milan Sreckovic [:milan] from comment #15)
> Actually, I don't think this is pan&zoom, and is probably tech-evangelism. 
> Using the +/- buttons on the Google Maps gives us the same bad behavior - it
> zooms based on the corner, then resets the item into the middle. That can't
> possibly be our code.

Then what's the regression range pointing to here in comment 8? Something had to change here that we caused, as we're not seeing this issue on a 10/22/2013 build.
Flags: needinfo?(jsmith)
Nick - Milan indicated that this might be due to the landing in bug 914847. What do you think?
Flags: needinfo?(ncameron)
I thought maybe the async animations were causing this - however, I disabled them with the layers.offmainthreadcomposition.async-animations pref, and I could still see the problem.  In case the animations are not the red herring, Markus, what do you think about bug 929362 related to this?
Flags: needinfo?(mstange)
Bug 914847 was backed out in the regression range from comment 8. I notice however that bug 927429 is in that range, which may have changed the UA string sent to google maps, and affected the content that we get from them. jchen says this is unlikely but it might be worth having somebody to run a build with the "general.useragent.updates.url" pref set to "" (empty string) to confirm.
Actually even more likely is bug 911260 which removed the UA override for google maps.
(In reply to Jason Smith [:jsmith] from comment #18)
> Nick - Milan indicated that this might be due to the landing in bug 914847.
> What do you think?

First, disabling OMTA wouldn't disable the effects of 914847, so that doesn't rule it out. That patch changes how reflows are done with touches - changing from a full flush to a mini-flush. That does match the timings in this bug, possibly. If there were a bug in the mini-flush code that affected the position of the zoom or something. However, I'm not sure if pinch to zoom counts as a touch. It should be kind of easy to test, although there is a fair bit of code, iirc, you can change from full flush to mini-flush or vice-versa with just a couple of lines of code in nsPresContext.cpp. I can make a patch if necessary.
Flags: needinfo?(ncameron)
No longer going to block on Mozilla-specific 1.3 blockers unless it hits a special exception list, so moving to 1.4? for triage.
blocking-b2g: 1.3+ → 1.4?
Vance - Can you check with TCL to see if this is a blocker for them or not?
Flags: needinfo?(vchen)
(In reply to Milan Sreckovic [:milan] from comment #19)
> In case the animations are not the red
> herring, Markus, what do you think about bug 929362 related to this?

Very unlikely. I'm with kats in comment 21 and expect this was caused by the UA string change in bug 911260.
Flags: needinfo?(mstange)
Confirmed this is a TE issue. This reproduces on FxAndroid with a FxOS UA spoof.
Blocks: 911260
blocking-b2g: 1.4? → ---
Component: Panning and Zooming → Mobile
Flags: needinfo?(vchen)
Product: Core → Tech Evangelism
Version: 28 Branch → unspecified
I'm not sure why you added Bug 911260 :) but removing it. This is a closed bug and unrelated. What did you want Jason? :)
No longer blocks: 911260
(In reply to Karl Dubost :karlcow from comment #27)
> I'm not sure why you added Bug 911260 :) but removing it. This is a closed
> bug and unrelated. What did you want Jason? :)

When a regressing patch is identified, we typically tag the bug as blocking the issue to link the two bugs together to indicate what caused the issue. The diagnosis on this bug has already firmly concluded that this was caused by bug 911260 because that bug removed the UA override for maps.google.com, which changed the content served to Firefox OS. The current content served to Firefox OS is still sub-optimal, as zoom in/out isn't working correctly.

We need to re-add the override here for maps.google.com.
Blocks: 911260
I'm getting a black screen on google maps now. (9 apr trunk)
(In reply to Jason Smith [:jsmith] from comment #28)
> The diagnosis on this bug has already firmly concluded that this was caused
> by bug 911260 because that bug removed the UA override for maps.google.com,

Bug 911260 is the bug for multiple patches. Not only maps.google.com. The patch has been delivered. This is a fact :)

I would rather prefer 
Option 1. we create a new bug. (this is my favorite)
or Option 2. we reopen the Bug 802981

That said I'm not in favor of adding again UA override. Let me do some tests and contacts first.


> which changed the content served to Firefox OS. The current content served
> to Firefox OS is still sub-optimal, as zoom in/out isn't working correctly.
> 
> We need to re-add the override here for maps.google.com.
(In reply to Karl Dubost :karlcow from comment #30)
> (In reply to Jason Smith [:jsmith] from comment #28)
> > The diagnosis on this bug has already firmly concluded that this was caused
> > by bug 911260 because that bug removed the UA override for maps.google.com,
> 
> Bug 911260 is the bug for multiple patches. Not only maps.google.com. The
> patch has been delivered. This is a fact :)

That makes it the regressing cause - it removed the UA override for maps.google.com, which revealed this bug in daily builds.

> 
> I would rather prefer 
> Option 1. we create a new bug. (this is my favorite)
> or Option 2. we reopen the Bug 802981

Both of these options don't make sense to me. The bug here is well communicated about the problem here - it's got STR, it's got a video, etc. bug 802981 is not the same as this issue - that issue deals with the fact that google maps isn't failing to load, where as this is a functionality issue with google maps.

> 
> That said I'm not in favor of adding again UA override. Let me do some tests
> and contacts first.

That doesn't make sense to me - this is basically lining yourself up to get complaints from our users, as they'll think something regressed, when in reality we removed the UA override too early.
(In reply to Jason Smith [:jsmith] from comment #31)
> (In reply to Karl Dubost :karlcow from comment #30)
> > (In reply to Jason Smith [:jsmith] from comment #28)
> > > The diagnosis on this bug has already firmly concluded that this was caused
> > > by bug 911260 because that bug removed the UA override for maps.google.com,
> > 
> > Bug 911260 is the bug for multiple patches. Not only maps.google.com. The
> > patch has been delivered. This is a fact :)
> 
> That makes it the regressing cause - it removed the UA override for
> maps.google.com, which revealed this bug in daily builds.
> 
> > 
> > I would rather prefer 
> > Option 1. we create a new bug. (this is my favorite)
> > or Option 2. we reopen the Bug 802981
> 
> Both of these options don't make sense to me. The bug here is well
> communicated about the problem here - it's got STR, it's got a video, etc.
> bug 802981 is not the same as this issue - that issue deals with the fact
> that google maps isn't failing to load, where as this is a functionality
> issue with google maps.

is failing to load*
OK after testing I agree with the effect that there's a panning which I can't reproduce on Firefox Android (Firefox 28 on GT-i9100) (but on a bigger screen than Firefox OS). The site is working, it just has an annoying glitch.

On the network resources side, for Firefox OS and Firefox Android, I receive exactly the same resources. So we are not sent a different version.  It might then be related to a keyword into the JavaScript triggered by Android identification. 

> as they'll think something regressed, when in reality we removed the UA override too early.

We didn't it was working when it was removed. :)

And before adding a UA override I want to know what is creating the issue.

<offtopic>
As for 
>  bug 802981 is not the same as this issue

Bug 8022981 is the reason why the UA override was added and it's why I said open a new bug to request UA override.  But interesting because the "real" bug for adding the UA override on maps.google.com was Bug 816823, but the whiteboard flag [uaoverride] was on bug 802981.
The UA override flag was added  by Lawrence Mandel [:lmandel] on 2013-07-11 01:11:34 JST  https://bugzilla.mozilla.org/show_bug.cgi?id=802981#c24

This convinces me that we should really separate identified issues from UA override bugs :) 
</offtopic>
No longer blocks: 911260
(In reply to Karl Dubost :karlcow from comment #33)
> OK after testing I agree with the effect that there's a panning which I
> can't reproduce on Firefox Android (Firefox 28 on GT-i9100) (but on a bigger
> screen than Firefox OS). The site is working, it just has an annoying glitch.

This isn't at the severity of a glitch. This means that you are zooming into a different location than the user requested. It's a functionality issue.

For the record, I can reproduce this. You need to be zoomed out all the way & then try to zoom in.

Side note - can you stop removing the blocking bug here? This is exactly how we track regressing causes in Bugzilla, which has already proven by the above window testing.
Blocks: 911260
Jason(In reply to Jason Smith [:jsmith] from comment #34)
> For the record, I can reproduce this. You need to be zoomed out all the way
> & then try to zoom in.

Me too. I didn't say the opposite. :)
Not sure why you **seem** to be annoyed. :) so let's see if I can explain a bit more here. We are saying the same thing here:

https://bugzilla.mozilla.org/show_bug.cgi?id=990767#c34
As in the bug above I can reproduce on Firefox OS, 
and I can't reproduce on Firefox Android, which is what is said in the bug in the first place. :)

As for the regression, I understand what you are saying. 
But there is something I see differently than you. The UA override removal is **not the cause of the issue**, It's not a regression. Comment #21 is wrong :) When we removed the UA override, there was NO issue. ;)

Comment #28 is also wrong

> that bug removed the UA override for maps.google.com, which changed the content served to Firefox OS.

We are being served the same content with both UA strings to the bytes count itself. :) Test it if you wish.


It's just a new issue, which might need adding a UA override. The two are not connected. Is it clearer? :)
(In reply to Karl Dubost :karlcow from comment #35)
> Jason(In reply to Jason Smith [:jsmith] from comment #34)
> > For the record, I can reproduce this. You need to be zoomed out all the way
> > & then try to zoom in.
> 
> Me too. I didn't say the opposite. :)
> Not sure why you **seem** to be annoyed. :) so let's see if I can explain a
> bit more here. We are saying the same thing here:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=990767#c34
> As in the bug above I can reproduce on Firefox OS, 
> and I can't reproduce on Firefox Android, which is what is said in the bug
> in the first place. :)
> 
> As for the regression, I understand what you are saying. 
> But there is something I see differently than you. The UA override removal
> is **not the cause of the issue**, It's not a regression. Comment #21 is
> wrong :) When we removed the UA override, there was NO issue. ;)
> 
> Comment #28 is also wrong

How do you know that? What proof do we have that this didn't reproduce right after the UA override was removed?
(In reply to Jason Smith [:jsmith] from comment #36)
> How do you know that? What proof do we have that this didn't reproduce right
> after the UA override was removed?

Each time, we decide to remove the UA override, one of us has checked that the site is working without the UA override. On my Open ZTE, I have removed the UA override totally. 

btw, not sure if you are aware but I made a script to remove that.
https://github.com/karlcow/webcompat/blob/master/moz/mozua2.sh

For visual proof, I didn't take a movie or a screenshot. So you will have to trust me on that. :)

Also about this specific part

> this didn't reproduce right after the UA override was removed.

You seem to still conflate two different bugs. :)
An history :)

* 2012-10-18 - Bug 802981 - Cannot navigate maps.google.com in browser app on the device 
* 2012-11-30 - Bug 816823 - Add UA override for maps.google.com
* 2012-12-01 -              # Patch added to the bug
* 2012-12-06 -              # Patch landed in gaia
* 2013-08-14 - Bug 802981   # Contacted Google (someone Chris H. on Google Maps team)
* 2013-08-31                # "I tested after removing the UA override."
* 2013-08-31                # Set as fixed.
* 2013-10-15 -              # efrat tested on locales that it fails. No UA override for locales
* 2013-10-23 - Bug 911260   # Patch landed for removing the UA override for maps.google.com
* 2013-10-15 - Bug 802981   # I followed up with Chris H. because it failed on locales.
* 2013-11-07 - Bug 802981   # Fixed for locales.

[… Time… time… time…]

* 2014-04-02 - Bug 990767 - [B2G][Browser]zooming in/out in google maps does not display properly
                            # This bug. Starts of an epic discussion on a new type of bugs 
                              that UA override would "solve". :)
             

What I guess is that Google has slightly changed their JS and it fails in a different way.
Btw another issue which is cosmetics is the background image on the button which does not display both on Firefox OS and Firefox Android. I haven't figured out exactly why.
(In reply to Karl Dubost :karlcow from comment #37)
> (In reply to Jason Smith [:jsmith] from comment #36)
> > How do you know that? What proof do we have that this didn't reproduce right
> > after the UA override was removed?
> 
> Each time, we decide to remove the UA override, one of us has checked that
> the site is working without the UA override. On my Open ZTE, I have removed
> the UA override totally. 
> 
> btw, not sure if you are aware but I made a script to remove that.
> https://github.com/karlcow/webcompat/blob/master/moz/mozua2.sh
> 
> For visual proof, I didn't take a movie or a screenshot. So you will have to
> trust me on that. :)
> 
> Also about this specific part
> 
> > this didn't reproduce right after the UA override was removed.
> 
> You seem to still conflate two different bugs. :)
> An history :)

I'm not confusing bugs here - I'm asking specifically if the bug as *filed* here was or wasn't reproducing post the removal of the UA override. That would determine if this is a site regression or if this always existed with a FxOS UA.
(In reply to Jason Smith [:jsmith] from comment #38)
> I'm asking specifically if the bug as *filed*
> here was or wasn't reproducing post the removal of the UA override. That
> would determine if this is a site regression or if this always existed with
> a FxOS UA.

The bug didn't exist. I already replied to that. :)
No longer blocks: 911260
I think Jason and Karl have cleared up the confusion evident in comments 27-39.

In case it isn't well known, UA overrides work against evangelism efforts. As such, it is preferable not to add an overrides= unless we have a strong case for it. This typically requires:
1. investigation to prove that the override will resolve the issue
2. some form of outreach that has not yielded a fix

It may also not be well known that we have decoupled the UA override mechanism from B2G releases. This means that we can push an override at any time (takes up to 1 week to deploy).
Could someone please document an example UA string this is reproducable with? I can't reproduce in 1.4 on my Peak (but it may still be spoofing, haven't had time to check)
Hallvord,

Reproducible on my ZTE Open, 
"Mozilla/5.0 (Mobile; rv:26.0) Gecko/26.0 Firefox/26.0"
By emulating Firefox OS UA on desktop and activating responsive view + touch. We can't really do zooming by pinching. But we can click "tap" on +/- and if we are careful enough we can notice the same issue.

I tried with different screen sizes and it exhibits the same issue.

I wonder if it's related to 

function alignWithMapCenter(ids) {
    for (var map = e('map'), centerLeft = Math.round(map.offsetWidth / 2), centerTop = Math.round(map.offsetHeight / 2), i = 0;
    i < ids.length;
    ++i) {
        var element = e(ids[i]);
        element && (element.style.left = centerLeft + 'px', element.style.top = centerTop + 'px')
    }
};
Assignee: nobody → kdubost
Whiteboard: [country-all] [notcontactready]
Note that with the same setup in Comment #43 but just changing UA to Firefox Android, fixes the issue. So there is really something fishy, somewhere.
Debugging this with devtools is harder than it should be due to bug 1010150, but I'll keep looking..
Hallvord, I see we have kind of dropped the ball on this one. 
Could we finish the analysis so we can bounce the issue to Google.

The issue still exists as of today on Firefox OS 2.1
Status: NEW → ASSIGNED
Duplicate of this bug: 1048449
Flags: needinfo?(hsteen)
Working code contains:

        (function() {
            window.gDeviceCapabilities = [, , true];
        })();

Not working code contains:

        (function() {
            window.gDeviceCapabilities = [, true, true];
        })();

Removing the first "true" in the latter array changes zoom behaviour. This is set by backend browser sniffing. I guess this may be a performance hack to avoid laggy zoom on less powerful phones.
Flags: needinfo?(hsteen)
Whiteboard: [country-all] [notcontactready] → [country-all] [contactready] [serversniff]
This is still the case. Tested today.
Also tested faking chrome mobile android UA on desktop and the behavior is correct and the map is working well when zooming.
See Also: → 1146609
See Also: → 1169983
Note that this particular bug is likely not testable at the moment, due to:
 - bug 1146609 - pinch zooming (2-finger / multitouch zooming) having no effect
 - bug 1169983 - zoom buttons (visible in comment 1's video) are no longer showing up

Double-tap-to-zoom is the only type of zooming that works on Google Maps at the moment.
Also: Firefox OS is now being served a more modern version of Google Maps' web UI than the version displayed in comment 1's video.  There's now a floating search box at the top of the screen, and the locate-me/directions buttons shifted to float at bottom-right.

Compare attachment 8613307 [details] (google maps in Firefox OS 3.0, screenshotted this morning) to the UI in the comment 1's video.

So, it seems possible that this bug may be gone in the more modern Google Maps verison, though we can't be sure at the moment, due to the bugs mentioned in comment 50.
Duplicate of this bug: 1177629
QA Whiteboard: [top-dogfood]
Recent dupes of this bug are probably really dupes of bug 1146609. See comment 50.

(This bug here is about zooming causing a weird effect on google maps; not about it not working at all.)
Flags: needinfo?(nhirata.bugzilla)
...or rather, they're probably dupes of bug 1150284, which is reportedly fixed in spark builds as of very recently (!)
Thanks for the need info/bug listings!

looking at the two bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1146609#c5 had suggested that it wasn't in our code.
https://bugzilla.mozilla.org/show_bug.cgi?id=1150284#c33 suggests that the fix will break other maps.
Will need to do some testing around this.
Duplicate of this bug: 1178034
Duplicate of this bug: 1179115
With a build that has the patch ( https://bugzilla.mozilla.org/show_bug.cgi?id=1150284#c33 ) , 
https://tools.taskcluster.net/task-inspector/#jhaqYYjDRwyprcZW28P3jg/0

It seems to work fine for google maps (though GPS is busted for google maps), tomtom works, and a few others work.  ( zMaps, Here maps )  Works meaning GPS + zoom in/zoom out.

I think we need a new dogfood build.
We've had two gecko updates since the time of this bug, does the first OTA resolve the issue?
Flags: needinfo?(nhirata.bugzilla) → needinfo?(dholbert)
It's working for me now.

As you noted, GPS still not working for Google Maps.
The recent OTA resolves the issue that was blocking Google maps from supporting multitouch zoom at all, yes. (Though that is different from this bug.)

This bug does seem to be fixed, too - I don't see anything like what's described in comment 0 or in the youtube video in comment 1. (And we're served a completely different version of Google Maps from when this bug was filed.)

Marking as WORKSFORME, since who knows when the original bug here was fixed (or if it simply became fixed by Google serving us their more modern interface).
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(dholbert)
Resolution: --- → WORKSFORME
(I do see jerkiness when zooming, but that's covered by bug 1181648.)
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.