1072896 - [B2G 2.0] [Browser] Zoom inconsistent when double tap on PC version of Naver website

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect)

Description

[Sridhar A]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20140909030207

Steps to reproduce:

1. Open browser and type http://www.naver.com.
2. Switch from mobile version to PC version (available at bottom of the page).
3. Double tap to zoom in/out at different places on the screen


Actual results:

Zoom IN/OUT of the webpage content is inconsistent.
Refer to the attached video.


Expected results:

Zoom In/Out should be consistent

Comment 1

[Sridhar A]

Attachment: Browser-doubletap-zoom-issue.zip

Comment 2

[Sridhar A]

Attachment: Browser-doubletap-zoom-issue.z01

Comment 3

[Sridhar A]

Attachment: Browser-doubletap-zoom-issue.z02

Comment 4

[Sridhar A]

Attachment: Browser-doubletap-zoom-issue.z03

Comment 5

[Sridhar A]

To watch the video, download all the four attached files to a folder. 
And use winzip to extract the video.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

I'm unable to unzip this on either Mac or Linux, and I don't have a windows machine. Please put the video in one piece somewhere, either on Youtube or some file-sharing service.

Comment 7

[Botond Ballo [:botond]]

I unzipped the video file and uploaded it to http://people.mozilla.org/~bballo/Browser-doubletap-zoom-issue.mp4. (The trick is to concatenate the parts.)

Comment 8

[Sridhar A]

I have tested the PC version of Naver website on an Android phone. When double tap on the screen, I couldn't observe scroll up/down of the web content after zoom-in. Zoom IN/OUT is consistent in this case.

In the video (http://people.mozilla.org/~bballo/Browser-doubletap-zoom-issue.mp4), we can observe in some of the cases when I double tap on the screen, the web content Zooms-in and scrolls up/down. Similarly, with the case of Zoom-Out.

Build Information:
OS Version : B2G 2.0.0.0
Git commit info: 2014-08-29 20:13:12
449d8db9

Comment 9

[Kartikaya Gupta (email:[e-mail])]

(In reply to Botond Ballo [:botond] from comment #7)
> I unzipped the video file and uploaded it to
> http://people.mozilla.org/~bballo/Browser-doubletap-zoom-issue.mp4. (The
> trick is to concatenate the parts.)

Thanks. I tried concatenation but it didn't work for me. Ah well.

(In reply to Sridhar A from comment #8)
> I have tested the PC version of Naver website on an Android phone. When
> double tap on the screen, I couldn't observe scroll up/down of the web
> content after zoom-in. Zoom IN/OUT is consistent in this case.
> 
> In the video
> (http://people.mozilla.org/~bballo/Browser-doubletap-zoom-issue.mp4), we can
> observe in some of the cases when I double tap on the screen, the web
> content Zooms-in and scrolls up/down. Similarly, with the case of Zoom-Out.

I definitely see some odd behavior in the video but I'm not able to reproduce that behaviour on a master build. Very rarely I do manage to tap in some blank space between elements and it zooms in there unexpectedly instead of zooming out. I suspect we could probably improve our target selection heuristics here but they are going to be very dependent on the exact layout of the page and how wide elements are and so on. If you are able to create a simplified test page that isolates the problematic behavior it would be quite helpful.

Comment 10

[Sridhar A]

I have verified in some of desktop versions of other websites having more web content. I could see the  page is zooming in and scroll instead of zooming out when I double tap on the screen. Meanwhile, I am trying to create a test page which could show this problematic behaviour, it may take time.

Comment 11

[Rachelle Yang [:ryang][[e-mail]]]

Hi Sridhar, is there any progress or update of the test page you mentioned per comment10? 
Thank you very much !

Comment 12

[Sridhar A]

Attachment: Naver_test_page.rar

Comment 13

[Sridhar A]

Hi Rachelle, I have tried to create a test web page, but couldn't do so in reproducing this issue while tested on the device. So, I have saved the http://www.naver.com page to my PC and edited the NAVER.htm file in order to create a test page which could reproduce this issue when verified on device.

I have attached the edited NAVER.htm and files in https://bugzilla.mozilla.orgattachment.cgi?id=8500422.
Also, I have verified this edited test page and I could reproduce the zoom inconsistency in the device and the problematic behaviour mentioned in the above comments.

Please let me know if the attached test page was useful to work on.

Comment 14

[Rachelle Yang [:ryang][[e-mail]]]

Hi Kartikaya, with the test page provided in comment12, could you please look into the zoom inconsistency issue ?

Thank you very much!!

Comment 15

[Rachelle Yang [:ryang][[e-mail]]]

[Blocking Requested - why for this release]:
partner requested as blocker. nominate to 2.0 ?

Comment 16

[howie [:howie]]

qawanted, can we test the result when turning off APZC?

Comment 17

[Kartikaya Gupta (email:[e-mail])]

(In reply to howie [:howie] from comment #16)
> qawanted, can we test the result when turning off APZC?

I don't see a point to doing this. I'll take a look at the reduced test case later today.

Comment 18

[Kartikaya Gupta (email:[e-mail])]

The reduced test case is much better, thanks Sridhar! It would also help if you identified a specific region of the page somehow where you can double-tap to reproduce the incorrect behaviour. That way we'll all be in sync with respect to what exactly we're trying to fix.

Comment 19

[Joshua Mitchell (Inactive)]

striking tag based on comment 17

Comment 20

[Rachelle Yang [:ryang][[e-mail]]]

Hi Sridhar, thanks for the test page provided.

Per comment 18, would you mind helping us identifying a specific region to reproduce the incorrect behaviour easily ? 
Thanks you very much

Comment 21

[Sridhar A]

When I double tap on center or the right side region of the test page, I could observe the incorrect behaviour more. In other region, the page gets zoomed-in and scrolled and sometimes instead of zooming out it zooms in or scrolls unexpectedly.

Comment 22

[howie [:howie]]

Triage group: Blocking as requested by partner.

Comment 23

[Kartikaya Gupta (email:[e-mail])]

The code for this lives in BrowserElementPanning.js; moving components. Also I don't know if this is going to get fixed for 2.0.

Comment 24

[Kartikaya Gupta (email:[e-mail])]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #18)
> It would also help if
> you identified a specific region of the page somehow where you can
> double-tap to reproduce the incorrect behaviour. That way we'll all be in
> sync with respect to what exactly we're trying to fix.

Sorry if I wasn't clear. What I was thinking here is that you actually insert an element into the test page that unambiguously indicates where to double-tap to produce the bad effect. Tapping in the general "center" or "right side region" of the page produces very different results depending on where exactly you tap.

Comment 25

[Rachelle Yang [:ryang][[e-mail]]]

Hi Sridhar, could you please help to clarify the scenario per comment 24 ? Thanks

Comment 26

[Sridhar A]

Attachment: Naver_test_page_modified.rar

Comment 27

[Sridhar A]

When I have inserted the below <iframe> element under the <div> Tag "shopping_cast" in the test page, I could observe a group of icons on the page. When I double tap anywhere on those icons, the incorrect behaviour can be reproduced.

<div class="shopping_cast">

<iframe src="./NAVER_files/shopAdBox.htm" id="shop_cast" class="shop_cast" title="?????" marginheight="0" marginwidth="0" scrolling="no" frameborder="0" width="304" height="769">????? : &lt;a href="(none)"&gt;(none)&lt;/a&gt;</iframe>

</div>


For your reference I have attached a snapshot and the modified test page in https://bugzilla.mozilla.org/attachment.cgi?id=8502468

Please let me know if need more information.

Comment 28

[Kartikaya Gupta (email:[e-mail])]

Thanks, I posted your test case to http://people.mozilla.org/~kgupta/bug/1072896/ so people can try it more easily. I can reproduce some cases where double-tapping causes the page to "slide" rather than to zoom in/out. In all the cases I ran into that actually seemed like reasonable behaviour, because I was double-tapping on something that was only partially visible on the screen, and so it makes sense for the browser to bring that into view while remaining zoomed in.

I also tried double-tapping around this page in Fennec and there the behaviour is consistent with B2G. I'm not yet sure we have a specific case we can reproduce where the behaviour looks wrong.

Comment 29

[Sridhar A]

Hi Kartikaya, is there any progress or update on this issue and please let me know if you need any more information. Thank you very much.

Comment 30

[Kartikaya Gupta (email:[e-mail])]

Hi Sridhar, I think we still need more specific steps to reproduce before we can do anything here. As I mentioned in comment 28 I was not able to reproduce any unexpected behaviour using the setup you described.

Comment 31

[Sridhar A]

Attachment: Double_Tap_Area_Image.png

Comment 32

[Sridhar A]

Hi Kartikaya, I am verifying this test page on OS Version: 2.0.0.0 

Steps :
1. Open the test page (http://people.mozilla.org/~kgupta/bug/1072896/) in browser
2. Double tap on this area of test page (Refer to attached image : Double_Tap_Area_Image.png)

I could observe the page zooms-in and slides to the top right-side corner of the page, reproducibility rate is 100%.

Please let me know which OS version you were trying to reproduce it so that I can verify the same on my side.

Thank you.

Comment 33

[Kartikaya Gupta (email:[e-mail])]

Hi Sridhar, I am trying to reproduce on the latest master code (corresponds to Firefox OS 2.2) but am not able to. I have uploaded a video of what happens when I double-tap in that area on the test page: https://www.youtube.com/watch?v=ReJpvhK_-iQ

Comment 34

[Sridhar A]

Hi Kartikaya, thanks for providing the info. I have verified this issue on Firefox OS 2.2. 
When I double-tap in that area of the test page, I find the zoom is better when compared to version 2.0.
I request, if you could help me in providing the changes/patches details which I can uplift to version 2.0 to fix this issue.

Thank you.

Comment 35

[Kartikaya Gupta (email:[e-mail])]

To be honest I don't know what bugs or patches are responsible for this change in behaviour. The code that controls the zoom-to rect is at http://hg.mozilla.org/mozilla-central/annotate/62f0b771583c/dom/browser-element/BrowserElementPanning.js#l514 and most of it hasn't been touched for 2 years. I don't know what other changes might be responsible for this behaviour difference. We would probably need to check 2.1 to see if it happens there, and then bisect the relevant windows to see when it was fixed.

Comment 36

[Sridhar A]

Hi Kartikaya, I have verified this bug in version 2.1 with the test page, it is reproducible and behaviour is same as version 2.0.

Is it possible to know the relevant patches merged between version 2.1 and 2.2 which could have fixed this issue.

Thank you.

Comment 37

[Kartikaya Gupta (email:[e-mail])]

As I mentioned before I don't know which changes would have affected this behaviour. If you want to know the exact patches you'll have to bisect all the changes to see when the bug was fixed. However, I should warn you that it will likely be a waste of time because it's very unlikely that those patches will be upliftable to 2.0. There have been a lot of changes since 2.0 and attempting to backport a fix will be very risky.

:howie, since you were the one who marked this bug 2.0+ you should figure out if you care enough to do this bisection and if the release drivers will accept a risky uplift across what will likely be 3 gecko versions.

Comment 38

[howie [:howie]]

Hi Rachelle, the issue is fixed between 2.1 and 2.2. If you want qawanted to bisect which patch fixed this? And even the patch is found, as Kartikaya mentioned, it's risky to backport to 2.0.

Comment 39

[Rachelle Yang [:ryang][[e-mail]]]

Hi Howie, thanks for your recommendation.

Comment 40

[Joshua Mitchell (Inactive)]

Swapping QA-Wanted tag for Regressionwindow-Wanted tag which more accurately describes the requested work to be done even though it is a 'reverse' regression-window or a 'fixed' window the regressionwindow-wanted tag is what we generally use for that.

Comment 41

[Pi Wei Cheng [:piwei] (inactive)]

To clarify, the STR on comment 32 is only 100% reproducible on v2.0 if user double-taps on the target area WITHOUT scrolling down on the page. This bug is NOT reproducible on v2.0 if user scrolls down first before double-tapping target area.

This bug is reproducible on Flame 2.0.

Observed behavior: Without scrolling down first, device zooms to an incorrect area on upper right of the page when double tapping on lower right (target) area specified on comment 32. Repro rate: 10/10.

Device: Flame 2.0 (shallow flash, 319MB mem)
BuildID: 20141020025114
Gaia: 63b56a7a7453726b9e12ad1afe02c68c83c5aeca
Gecko: 09b9387be5ad
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

--------

This bug is NOT reproducible on Flame 2.1 and Flame 2.2 Master.

Observed behavior: Target area is zoomed-in as expected with or without scrolling down first. Repro rate: 0/15 on v2.1, 0/10 on v2.2.

Device: Flame 2.1 (shallow flash, 319MB mem)
BuildID: 20141020072210
Gaia: 6456e9d03a6f9a226818a1bccefc489a9bb7cb56
Gecko: 105d1bb4180f
Version: 34.0 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.2 Master (shallow flash, 319MB mem)
BuildID: 20141020055012
Gaia: dc496d04907dd314f9736ff78bab3bd27156f79a
Gecko: f2d7d694aae5
Version: 36.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

--------

As comment 40 stated, a reverse window will be attempted to find out what fixed the issue.

Comment 42

[Pi Wei Cheng [:piwei] (inactive)]

This issue is fixed by the implementation of Browser2.

Last Broken Environmental Variables:
Device: Flame
BuildID: 20140818130516
Gaia: 778c39b5597ea424d6a75934221265423ab3c9e7
Gecko: cd7cbdacf9d8
Version: 34.0a1 (2.1 Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First Working Environmental Variables (working because Browser2 is available; on the same build if using old Browser the issue is still reproducible):
Device: Flame
BuildID: 20140818173616
Gaia: b33b4d9558e0b9eabbfda7be23435e2b38fd40bf
Gecko: 111a1da2a95d
Version: 34.0a1 (2.1 Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 43

[Joshua Mitchell (Inactive)]

NI to Rachelle to see comment 42

Comment 44

[Rachelle Yang [:ryang][[e-mail]]]

[Blocking Requested - why for this release]:

Triage again， high risk to land on 2.0. 
While there might be a fix in 2.1 and 2.2

Comment 45

[Rachelle Yang [:ryang][[e-mail]]]

Per comments above, since the patch is high risk to land on 2.0. Triage to denominate it for now.

Comment 46

[Kartikaya Gupta (email:[e-mail])]

Closing WFM since this is fixed in newer versions and we don't plan on uplifting.