User Agent: Mozilla/5.0 (Android; Mobile; rv:21.0) Gecko/21.0 Firefox/21.0 Build ID: 20130430202604 Steps to reproduce: After any page loads. Pinch to zoom in and the display jumps to some other random spot on the page after zooming, instead of zooming to the center location. zooming back out does the same thing. Actual results: pages jump on zooming in and out instead of a smooth zoom. The spot I was looking at and attempting to zoom into does not remain. The page seems to jump up and left relevant to the top of the page. Never remains on the spot you are looking at when zooming. Expected results: smooth zoom in and out and remain focused on the spot in original position. I started to notice this approx 2 or 3 updates ago and is still there as of the update. 20130503

Do you see the same thing on dev-channel using Nightly (http://nightly.mozilla.org) for Android?

Do you have 'Pinch to reflow text' enabled? If so, can you reproduce by disabling it?

yes removing the check stops the odd behavior. now the zoom does not jump but it remains where it is supposed to. why what does that option do.

(In reply to Ibizian from comment #3) > yes removing the check stops the odd behavior. now the zoom does not jump > but it remains where it is supposed to. why what does that option do. Scott, how should pinch to zoom work in regard to the user not ending up to the same page position where one zooms in?

(In reply to Aaron Train [:aaronmt] from comment #4) > (In reply to Ibizian from comment #3) > > yes removing the check stops the odd behavior. now the zoom does not jump > > but it remains where it is supposed to. why what does that option do. > > Scott, how should pinch to zoom work in regard to the user not ending up to > the same page position where one zooms in? Aaron, the way it works is it attempts to identify a DOM range corresponding to where the user zooms in, and then locates the screen position of this dom range after the reflow has happened. It's possible that the user's actual position isn't quite what is expected - that is, where the user is reading might not actually correspond to where the point reflow-on-zoom is expecting to zoom in. The pinch gesture utilizes the midpoint between the two fingers to zoom into a given location, so it's probably pretty difficult to gauge from a UX perspective. Hence the reason bug 847872 was filed. I think we should defer the analysis of this bug until after bug 847872 lands (which should be this upcoming week - I'm just finishing the patch now). The reason being, I think this will solve a few of these positioning problems based on having a synchronous zoom method instead of this asynchronous method which is currently in place.

(In reply to Scott Johnson (:jwir3) from comment #5) > (In reply to Aaron Train [:aaronmt] from comment #4) > > (In reply to Ibizian from comment #3) > > > yes removing the check stops the odd behavior. now the zoom does not jump > > > but it remains where it is supposed to. why what does that option do. > > > > Scott, how should pinch to zoom work in regard to the user not ending up to > > the same page position where one zooms in? > > Aaron, the way it works is it attempts to identify a DOM range corresponding > to where the user zooms in, and then locates the screen position of this dom > range after the reflow has happened. > > It's possible that the user's actual position isn't quite what is expected - > that is, where the user is reading might not actually correspond to where > the point reflow-on-zoom is expecting to zoom in. The pinch gesture utilizes > the midpoint between the two fingers to zoom into a given location, so it's > probably pretty difficult to gauge from a UX perspective. Hence the reason > bug 847872 was filed. > > I think we should defer the analysis of this bug until after bug 847872 > lands (which should be this upcoming week - I'm just finishing the patch > now). The reason being, I think this will solve a few of these positioning > problems based on having a synchronous zoom method instead of this > asynchronous method which is currently in place. Also, this isn't what I'm seeing with pinch-to-zoom enabled. I'm not quite sure what the user is talking about here. Ibizian, can you give us an example video or web page that doesn't work with pinch-to-zoom and specific steps (e.g. "I pinched to zoom into the following words: 'abc defg hi...' and expected that these would be on the screen, but rather 'xyzta ozi isu' was on the screen").

I'm not sure how to do the video but what happens is the punch to zoom does it's zoom then the page slides all the way right then jumps up so it comes to a stop at almost the top one third of every page regardless of how deep i zoom. It completes the zoom correctly still centered on the say word i zoomed in on but then slides the page to the right as if you finger slide to the right.  That motion is smooth.  Then it jumps to the top. That motion is all at once no scroll just a jump. Is there a recommended app i could use to video screen shots for you guys?

Video shouldn't be required, I think the user is just describing the action taken after a pinch-zoom outwards with reflow on zoom enabled (the shift away from content you'd expect to be zoomed in on) you can see this on Bugzilla for example. > Is there a recommended app i could use to video screen shots for you guys? A lot of us just record the screen with a second device camera if you've got one.

going to the ever-needed http://www.cbc.ca/player/Shows/Shows/Coronation+Street/ID/2384884292/ for example and scroll to the bottom of the page (where the footer is). Double-tapping brings that section into focus in an 'ok' manner, but when I then pinch to zoom even more, it hiccups and jumps. Scroll around the page, double-tap and then pinch some more, you see lots of hiccups and jumps. I would expect that when I have pinched in further and I scroll, it is a smooth experience - no one is guessing what I'm trying to do at that point. Also on this page, if I were to double tap on the video area (with the hopes it will fit to screen, it either crashes or doesn't fit to screen (it zooms too far in). (I am providing you my real-life browsing examples and frustrations - you should be honoured I am sharing so much information here ;-) ). Karen

Another double-tap not working well (and without the pinch-to-zoom case). Go to autotrader.co.uk and select the desktop site (at the bottom). Then tap on the 'new cars and reviews' tab. Double-tap on one of the 'latest news' article introductions. The area zooms in nicely, but the text is not reflowing as expected - it is overflowing to the right.

(In reply to Karen Rudnitski [:kar] from comment #9) > going to the ever-needed > http://www.cbc.ca/player/Shows/Shows/Coronation+Street/ID/2384884292/ for > example and scroll to the bottom of the page (where the footer is). > Double-tapping brings that section into focus in an 'ok' manner, but when I > then pinch to zoom even more, it hiccups and jumps. Scroll around the page, > double-tap and then pinch some more, you see lots of hiccups and jumps. I > would expect that when I have pinched in further and I scroll, it is a > smooth experience - no one is guessing what I'm trying to do at that point. Does this behavior exist when double-tap to reflow is turned off? (I would expect not, but it's good to clarify my assumptions) > Also on this page, if I were to double tap on the video area (with the hopes > it will fit to screen, it either crashes or doesn't fit to screen (it zooms > too far in). So, this probably is a different issue. It might be good to open a different bug to track this one. > (I am providing you my real-life browsing examples and frustrations - you > should be honoured I am sharing so much information here ;-) ). I appreciate your detail. Thank you. (In reply to Karen Rudnitski [:kar] from comment #10) > Another double-tap not working well (and without the pinch-to-zoom case). Go > to autotrader.co.uk and select the desktop site (at the bottom). Then tap on > the 'new cars and reviews' tab. > > Double-tap on one of the 'latest news' article introductions. The area zooms > in nicely, but the text is not reflowing as expected - it is overflowing to > the right. Is double-tap to reflow text enabled? I'm not seeing this behavior on my Samsung Galaxy S2. Another thing to check is which version of Nightly you're using (i.e. the date of the nightly build). There were some versions of nightly that had double-tap to reflow text as an option, but the preference for controlling the text size was not set by default. Try navigating to 'about:config', and searching for 'browser.zoom.reflowZoom.minFontSizeTwips'. This setting should be set to '120'.

(In reply to Scott Johnson (:jwir3) from comment #11) > Does this behavior exist when double-tap to reflow is turned off? (I would > expect not, but it's good to clarify my assumptions) no - it is very smooth when it is turned off. > So, this probably is a different issue. It might be good to open a different > bug to track this one. ok > Is double-tap to reflow text enabled? I'm not seeing this behavior on my > Samsung Galaxy S2. Another thing to check is which version of Nightly you're > using (i.e. the date of the nightly build). There were some versions of > nightly that had double-tap to reflow text as an option, but the preference > for controlling the text size was not set by default. Try navigating to > 'about:config', and searching for > 'browser.zoom.reflowZoom.minFontSizeTwips'. This setting should be set to > '120'. It certainly is enabled. When when I disable it and double-tap, it zooms in as far as that column can go (without cutting anything off). So two different behaviours when the setting is on or off. I am using a Nexus 4 but on the May 28 build.

(In reply to Karen Rudnitski [:kar] from comment #12) > It certainly is enabled. When when I disable it and double-tap, it zooms in > as far as that column can go (without cutting anything off). So two > different behaviours when the setting is on or off. I am using a Nexus 4 but > on the May 28 build. So, when double-tap to reflow text is enabled, does it work properly (i.e. reflow text after double-tapping so that it's wrapped within the viewport) when on other pages besides the two you mentioned? I'm wondering specifically if it doesn't work on _any_ pages for you, or whether there are a set of pages that it doesn't work on.

I found one autotrader article that, although it was already quite narrow in the first place, I double-tapped and it zoomed in further and did some reflowing (save for a longer URL). So I can find some examples of it working. (I went to my other BBC.co.uk familiar site, clicked on a news article from the desktop version, but it is formatted in such a way that double-tap doesn't need further reflow.) I can try and find some other examples of it working, but I have at least found one where there is some text wrapping action going on.

(In reply to Karen Rudnitski [:kar] from comment #14) > I found one autotrader article that, although it was already quite narrow in > the first place, I double-tapped and it zoomed in further and did some > reflowing (save for a longer URL). So I can find some examples of it working. > > (I went to my other BBC.co.uk familiar site, clicked on a news article from > the desktop version, but it is formatted in such a way that double-tap > doesn't need further reflow.) > > I can try and find some other examples of it working, but I have at least > found one where there is some text wrapping action going on. Ok, thanks for debugging it a bit further. On the site(s) where it doesn't work, does the double tap zoom in quite a bit, or is it only a small increase in the amount that it zooms?

with it enabled, on the coronation street site, it doesn't seem in as much as when it is disabled. but on autotrader, it zooms in MORE when it is enabled than when it is disabled. Zooms in a fair bit on autotrader (which is good) but is iffy on the coronation street CBC site.

We removed double tap to reflow and users want it back, on bug 900564 (where we disabled it) this was a dependency. Is anyone working on this?

Comment on attachment 8346374 [details] [diff] [review] no_animate.patch >diff --git a/mobile/android/base/gfx/JavaPanZoomController.java b/mobile/android/base/gfx/JavaPanZoomController.java Kats should look at this part >diff --git a/mobile/android/chrome/content/browser.js b/mobile/android/chrome/content/browser.js > } >- >+ docViewer.pausePainting(); A blank line there seems nice >+ docViewer.resumePainting(); Should this be in a try/finally? I worry about an error getting thrown and then kills painting forever. >+ let docViewer = null; >+ let webNav = BrowserApp.selectedTab.window.QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.nsIWebNavigation); >+ let docShell = webNav.QueryInterface(Ci.nsIDocShell); >+ docViewer = docShell.contentViewer.QueryInterface(Ci.nsIMarkupDocumentViewer); >+ docViewer.pausePainting(); > Services.obs.notifyObservers(null, "after-viewport-change", ""); >+ if (docViewer) { >+ docViewer.resumePainting(); >+ } Same issue here. What happens when we get out of sync? I wish we had better control over the pause/resume system. What do Kats and DBaron feel about this API? Are these calls limited to double-tap, or do they get called a lot more? r+ from me on the semantic changes to browser.js, but I'd feel better if this got a review from Kats too.

Comment on attachment 8346374 [details] [diff] [review] no_animate.patch Review of attachment 8346374 [details] [diff] [review]: ----------------------------------------------------------------- This looks ok to me, but I share mfinkle's concerns about exceptions getting thrown and then getting stuck with painting paused. I also have a long-standing issue with the refloz code that reflozPinchSeen is never set to true anywhere in the code and so I think there's some dead code in setViewport that can be removed. Bug 922682 is tracking this and I would like to see it land before any additional changes are made.

Hi, had to backout this change from mc (and integration trees) as part of https://tbpl.mozilla.org/?tree=Fx-Team&rev=28f65c4592b9 - seems there is a regression on fx-team causing as example https://tbpl.mozilla.org/php/getParsedLog.php?id=32271205&tree=Fx-Team and https://tbpl.mozilla.org/php/getParsedLog.php?id=32271639&tree=Fx-Team and hoping this backout fix this