Steps to reproduces: 1.go into contacts and create a new contact; 2.tap the eidt box to input the name and number and so on; 3.go into settings-language. tap the select box to change language; Actual results: 1.In step 2 and 3, it can be operated easily and successfully. Actual results: 1.For these two type box, it is difficult to operate. The touch-screen has no response. Other select-box such as the click-box after the APN option can be operated easily.

We use the version containing the patch which Keven Kuo sent to us. It has solved the problem in some interfaces. But it is also difficult to operate in marketplace and maps interfaces. the interfaces can see the attachments.

REOPEN. partner feedback that bug 833983 did fix the contacts app issue but marketplace / maps is still having similar problems (in comment 3 and comment 4)

Hi, I could not reproduce this issue on Otoro (on which, Bug 833983 was reproduced), Gecko (gecko-18) e4a677c13bf35253fea99e6b85df1c707038d119 Gaia (v1-train) 6916e18d1f72936e892543cf4a104a7d457f78ad If this only happened on a specific device, I would think this is device-dependent instead of a Gaia issue.

If this cannot reproduce on Otoro, which is closest to the shipping hardware, not a blocker.

Add a new touch problem. when we slide up and down or zoom in or out the screen in browser, the operation is not very smooth. Whether it can be optimized or not?

Please use Inari or Ikura to try to reproduce. Thank you!

(In reply to Joe Cheng [:jcheng] from comment #5) > REOPEN. partner feedback that bug 833983 did fix the contacts app issue but > marketplace / maps is still having similar problems (in comment 3 and > comment 4) Hi all, for the tapping issue on marketplace, I found the touchmove event is preventDefault by the javascript loaded by marketplace website. It's probably a different issue to what happened in contact app. here is the JS stack while invoking preventDefault() (gdb) p xpc_PrintJSStack(cx, true, true, false) $172 = 0x4431c000 "0 anonymous() [\"https://marketplace.cdn.mozilla.net/media/js/mkt/consumer-min.js?build=4252284\":12]\n this = [object Object]\n1 anonymous() [\"https://marketplace.cdn.mozilla.net/media/js/mkt/consumer-min.js?build=4252284\":15]\n this = [object HTMLElement]\n2 anonymous(c = undefined, d = undefined, e = undefined, f = undefined, g = undefined, h = undefined, i = undefined, j = undefined, k = undefined, l = undefined, m = undefined, n = undefined, o = undefined, q = undefined, r = undefined, s = undefined, t = undefined, u = undefined, arguments = undefined) [\"https://marketplace.cdn.mozilla.net/media/js/mkt/consumer-min.js?build=4252284\":12]\n c = undefined\n d = undefined\n e = undefined\n f = undefined\n g = undefined\n h = undefined\n i = undefined\n j = undefined\n k = undefined\n l = undefined\n m = undefined\n n = undefined\n o = undefined\n q = undefined\n r = undefined\n s = undefined\n t = undefined\n u = undefined\n arguments = undefined\n this = [object HTMLBodyElement]\n3 anonymous() [\"https://marketplace.cdn.mozilla.net/media/js/mkt/consumer-min.js?build=4252284\":12]\n this = [object HTMLBodyElement]\n"

Thanks to :schien for the investigation. [+cc Market Place Dev] Hi Chris, Could you please help us understand why preventDefault is necessary for touchmove event for this case (see attachment 711168 [details])? This may cause it not easy to be clicked on some devices, like Inari. Thank you.

this is Partner cert blocker.

tef+ to at least figure out what's going on and what devices are affected. If 1.0.1 target devices aren't affected, we can't tef+ this.

Rudy, feel free to take yourself off as the assignee if you're not the best person. I'm thinking comment #11 was directed at cjones so I'm setting ni? on him.

Sorry, I don't understand the question. What code is calling preventDefault() and why?

Sorry, I wanted to ping Chris Van, Market place owner. This issue is due to preventDefault() is invoked in the touchmove event handler, so that it would not trigger click effect for the buttons in attachment 711168 [details]. From our test, this issue could be easily reproduced on Inari, but not that easy (still possible) to reproduce on Otoro/Unagi. Thanks.

Going to unassign myself from this, since this involves market place part and touch/click event handling, I am not the best person. Please feel free to let me know if you need other info.

Dear all, After checking the Market place issue on Inari: It will trigger a touchmove (with deltaX as "1") event easily when you tap/click on the touch panel of Inari. On Unagi, this kind of slight touch move would NOT occur (maybe it is by firmware filter or something). This touchmove behavior also caused Bug 837062 and we have a per app patch there to solve the issue in homescreen. As noted in Comment 10 & 11, preventDefault is called in touchmove event handler of Market place, and it makes Gecko not generate the click event. == Next step == 1. App side, we still need Market place dev. to help check whether preventDefault in touchmove is necessary, it is still easy to cause "no click" when you long press on the button, even on Unagi. 2. Driver/firmware level If possible, this issue should be resolved at driver/firmware level, we would won't need to configure a tap threshold in Gecko per various devices. Thank you.

Per comment 18, need Marketplace app comment on #1 #2 is being worked on with partner.

Anthony can you look into coment 18 #1?

As far as I can tell, the only place that this is done in the marketplace is on overlays (media/js/mkt/overlay.js) to prevent users that are scrolling from closing an open overlay. It is not fired across the board. Is there another place that you're seeing this occur that I'm perhaps missing?

Yes, we preventDefault() on touchmove to prevent the user from scrolling a modal screen. It seems that that event is being used to synthesize 'click'. is that correct?

Correct, and that's the right behavior per spec (at least, by my reading) If the preventDefault method of touchstart or touchmove is called, the user agent should not dispatch any mouse event that would be a consequential result of the the prevented touch event.

https://github.com/mozilla/zamboni/commit/99f6832 Fixed this in the Marketplace. We're not doing preventDefault on touchmove anymore. Thanks, everyone!

Hi Chris(:cvan), Thanks for your help to look into this. Could you please let us know when the modified version will go online so we can test it to verify this issue? Thank you.

I can answer that. The code should be live on marketplace-dev.allizom.org right now. It will be pushed to the production servers next Thursday.

(In reply to Lukas Blakk [:lsblakk] from comment #20) > Anthony can you look into coment 18 #1? If I'm reading correctly, this was fixed on the marketplace side. Is there anything we need to do on Gaia?

Hi all, We could reproduce the HERE Maps issue on another Inari device. Here is the investigation result: Similar to market place issue, this is caused by a preventDefault() in touchmove event handler. The code in onBeforeScrollMove() of combined.js will get DeltaY=1 and DeltaX=0, and invoke preventDefault() for touchmove event. On Unagi, Even when we got touchmove event, the DeltaX/Y will both be 0, and the code in HERE Maps would not do preventDefault() in this case. As market place, it would be better to have HERE Maps Dev to check if that preventDefault() is necessary. Thank you.

Need someone to include HERE Maps dev into this bug for further comment on comment 28. Thanks

Adding needinfo on one of the Nokia contacts we typically talk to for comment 28.

I emailed Andy and got a vacation response that he's at MWC. Is there someone else we can contact at Nokia?

Hi all, The problem is that if you have a horizontal scrollable area on your vertical scrollable page (e.g. image gallery) you still want to allow the user scrolling vertically the whole page if their finger is on this area. As we use iScroll for scrolling we had to implement preventDefault accordingly to their documentation: https://groups.google.com/forum/#!searchin/iscroll/onBeforeScrollStart/iscroll/ESlql_dv-kY/uyML6VjU1bUJ BTW, it works perfectly fine on Unagi. Br, Leo

Unassigning myself as this is not a Gaia issue, AFAICT.

With all of this back and forth discussion I'm starting to get confused on what's the actual blocking factor on this bug and what we are actually doing here. Renom.

This is apparently on the Maps app side and will be fixed by an update in the marketplace of the Maps app soon.

Hi Lucas, I was probably not clear enough. The preventDefault is needed because otherwise the user is not able to scroll the page vertically if his finger is on the area which is supposed to be scrolled horizontally by iScroll library. This library is pretty popular between web developers because older Android and iOS devices don't support overflow-scroll. That means that all the thousands developers using iScroll will face the same problem. We'd really appreciate your help. Do you have a fix or a workaround to solve this problem? Leo

The underlying problem that Leo is explaining is this: you cannot prohibit developers from using preventDefault. It's a w3c standard and there are valid use cases for applying that to any web app. (One such use case is demonstrated in the iScroll library, which is extensively used by web app developers to get advanced scrolling behavior in javascript apps. )

Chris Jones - Can you address comment 36 and comment 37? This sounds like a request on touch events. Didn't we just fix something in this arena with the lanyrd mobile bug?

It would be very helpful if someone would cleanly summarize the problem here. All I know is what I cited in comment 23.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #23) > Correct, and that's the right behavior per spec (at least, by my reading) > > If the preventDefault method of touchstart or touchmove is called, the > user agent should not dispatch any mouse event that would be a consequential > result of the the prevented touch event. The "click" event is not a "consequential result" of the touchmove event (since the click would happen whether or not the touch point moved) so it should not be prevented when preventDefault is called on touchmove. Probably this section of the spec should not mention touchmove at all. Gecko gets this right in the Android and Windows builds that I tested. In this testcase, tapping on the "touchstart.preventDefault()" box does *not* generate a click, but tapping on the "touchmove.preventDefault" box *does* generate a click. If B2G behaves differently, I would consider that a B2G bug. If B2G behaves the same as Firefox for Android, then I'm not sure what's causing the problem described here.

It looks like this is indeed a B2G-specific bug, since the gPreventMouseEvents flag written by PresShell on preventDefault is read only in TabChild.cpp, which I believe is currently used only on B2G: http://mxr.mozilla.org/mozilla-central/ident?i=gPreventMouseEvents

If the case mentioned in Comment 36 & 37 is a justified case for using preventDefault in touchmove, we should consider to solve this issue by Part 2 in Comment 18 to filter out this unnecessary "touchmove" with DeltaX or DeltaY = 1. --- 2. Driver/firmware level If possible, this issue should be resolved at driver/firmware level, since we won't need to configure a tap threshold in Gecko per various devices.

I think the fix should look like this, but I don't have a B2G device so I'm not the best person to work on this. Who can test this out, and make any fixes that are necessary?

Maybe Chris Peterson should look at this.

Comment on attachment 722297 [details] [diff] [review] untested patch Er, why are we using gPreventMouseEvents in TabChild? We should make b2g/TabChild code look closer to what other widgets do.

remove myself from needinfo since @mbrubeck already point out the solution in comment 40.

I think we should fix this. It's being a while that many page in LINE app is very hard to access and it turns out it's due to this issue. On MDN page even has a suggestion to call preventDefault on touchmove[1] to not break "click" [1]: https://developer.mozilla.org/en-US/docs/Web/API/Touch_events#Handling_clicks

I intend to work on this so assign to myself.