741247 - Touch events aren't consistently triggered especially on the right sides of elements

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Ming-Yee Iu]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.142 Safari/535.19

Steps to reproduce:

I'm making an HTML5 game, and I noticed that the touch events don't trigger on certain parts of the screen. It seems to happen on some html5 demos that I've tried too. For example, if you go to http://paulirish.com/demo/multi, then use two fingers to zoom out a bit, then move to the far right side of the window. You can't seem to initiate touchstart events on the far right side of the canvas because it gets grabbed by the window scrolling handler. But you can initiate touchstart events on the left side of the screen and then have the touch move events continue triggering as you move your finger to the far right side of the element.


Actual results:

touch events aren't being triggered by Firefox. Firefox seems to be grabbing them and using them for window scrolling or something


Expected results:

Firefox should fire the touch events and let the touch event handlers call preventDefault() to prevent Firefox from using them for window scrolling.

Comment 1

[Aaron Train [:aaronmt]]

Which build did you test with?

Comment 2

[Ming-Yee Iu]

The nightly: 14.0a1, 2012-4-1 (though I've had similar, but different touch problems on earlier versions of Firefox involving event bubbling)

Comment 3

[Wesley Johnston (:wesj)]

Hmm.. how close to the edge are we talking?

On the paul irish demo, if I start my touch off the edge of my tablet I get seemingly random pans vs. drawing. I think that is because there is a thin area between the canvas and the edge of the page.

Other than that, things seem to work fine. Device name and OS version would be helpful as well.

Comment 4

[Ming-Yee Iu]

I'm running on a Nexus S, 2.3.6. Make sure you resize things first. I can only get it to occur in the paul irish demo when I shrink things a bit before scrolling over to the right side. I'm not sure if it will occur on a tablet since things may not get resized there. Then, the right edge of the canvas element has problems receiving touchstart events.

Comment 5

[Ming-Yee Iu]

Alternately, you can just try the game directly. If you go to http://games.user00.com/EndlessRoad/index.html and then touch "start". I've hooked the touch handlers for the document, and I display the pageX and pageY of all the touch events in the upper-right of the game. Depending on the zoom level, you will see that the control buttons on the right side of the game do not register any touches.

Comment 6

[Wesley Johnston (:wesj)]

Cool. I can reproduce this on my phone. Digging in

Comment 7

[Brad Lassey [:blassey] (use needinfo?)]

Wes how common is this problem? Does it effect any major sites?

Comment 8

[Wesley Johnston (:wesj)]

I haven't seen it before this. Am still trying to track down what's going on. On the paul irish demo site, we also don't send MOUSE events to the right side of the page (if you zoom it out to full width). I (currently) think we are not using the transform in nsLayoutUtils::GetFramesForArea.

Comment 9

[JP Rosevear [:jpr]]

Dupe of bug 740005?

Moving to new since Wes can dupe.

Comment 10

[Wesley Johnston (:wesj)]

Not sure if that's the same or not. I think bug 74005 (at least the versions of it I have seen) have to do with Java code not knowing the viewport correctly and sending us messages with incorrect aX and aY coordinates.

I reduced the Paul Irish testcase here:
http://dl.dropbox.com/u/72157/irish.html

And did a bunch to get some logging messages. Basically though, I've found that the display list at:

http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp#1432

is empty. Strangely(?) it looks like when we dispatch events from browser.js, they appear there with the same coordinates, but do have a display list.

Comment 11

[Wesley Johnston (:wesj)]

Cwiiis, can you give me any guidance here, on whether this makes sense? When I output the display list for doing hit detection (when tapping on the left side of my example) I see:

Background 0x47ae0cb0() (0,0,28800,44640)(0,0,28800,44640) uniform
Background 0x47ae0e10() (0,0,28800,44640)(0,0,28800,44640) uniform
Clip 0x0() (0,0,28800,44640)(0,0,0,0)
  Background 0x47ae1bf8() (0,0,28800,44640)(0,0,28800,44640) uniform
  Background 0x47efc158() (0,0,28800,44640)(0,0,28800,44640) uniform
Clip 0x0() (0,0,28800,44640)(0,0,0,0)
  Clip 0x47efc158() (0,0,28800,44640)(0,0,28800,44640)
    OwnLayer 0x4aa9e020() (0,0,58800,91140)(0,0,58800,91140)
      Background 0x4aa9e7f8() (0,0,58800,91140)(0,0,58800,91140) uniform
        Clip 0x0() (0,0,58800,91140)(0,0,0,0)
        ScrollInfoLayer 0x4aa9e620() (0,0,0,0)(0,0,58800,91140)
        ScrollLayer 0x4aa9e620() (0,0,58800,91140)(0,0,58800,91140)
          CanvasBackground 0x4aa9e620() (0,0,58800,91140)(0,0,58800,91140) uniform
          Background 0x4aa9f4f8() (0,0,58800,19320)(0,0,58800,19320) uniform
        Clip 0x0() (0,0,58800,91140)(0,0,0,0)
          ScrollLayer 0x4aa9e620() (480,480,57840,18360)(0,0,58800,91140)
            Background 0x4aa9f930() (480,480,57840,18360)(0,0,57840,18360) uniform
        Clip 0x0() (0,0,58800,91140)(0,0,0,0)
          ScrollLayer 0x4aa9e620() (480,480,55680,18360)(0,0,58800,91140)
            Background 0x4aa9fc58() (480,480,55680,18360)(0,0,55680,18360) uniform
            Border 0x4aa9fc58() (480,480,55680,18360)(0,0,55680,18360)
            nsDisplayCanvas 0x4aa9fc58() (660,660,55320,18000)(0,0,55680,18360)

But I can also see us setting our CSSViewport and Displayport to 58800x91140 (i.e. everything is visible). So it looks to me like we're clipping to... something. roc suggested it might be the browser element we're drawing into. That makes sense to me. I guess we need to apply our DisplayPort transform on its parent CLIP rect?

Comment 12

[Wesley Johnston (:wesj)]

Realized what's up on the way home. We're transforming these event coordinates to the display port of the current tab in Java before sending them to Gecko. I think maybe we'll need to send down the untransformed coordinates, and then transform coordinates at each place in our hit detection?

That will also mean we may need to modify the dom code for getting page/client/etc coordinates for the event in nsDOMEvent::GetPage/Client/Screen coords.

Comment 13

[Chris Lord [:cwiiis]]

(In reply to Wesley Johnston (:wesj) from comment #12)
> Realized what's up on the way home. We're transforming these event
> coordinates to the display port of the current tab in Java before sending
> them to Gecko. I think maybe we'll need to send down the untransformed
> coordinates, and then transform coordinates at each place in our hit
> detection?
> 
> That will also mean we may need to modify the dom code for getting
> page/client/etc coordinates for the event in
> nsDOMEvent::GetPage/Client/Screen coords.

I'm not sure I understand this, I'll ping you on IRC about it later.

Comment 14

[Martijn Wargers (dead)]

I noticed that stuff inside CSS -moz-transform elements are difficult to click upon. I filed bug 744353 for it. Is it related to this bug?

Comment 15

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Two things would be very helpful here
 (1) Small test case posted to this bug that shows the problem
 (2) Description of what actors are transforming which input events to what coordinate spaces at each point in the pipeline between receiving the input event in lowest-level java-widget code and dispatching it to web content.  We'll likely need multiple people to fill this in.  Wes, if you can list the pieces between java-widget and dispatch-to-gecko that would be a great start.  An assumption is most likely being violated at some point in that chain.

Comment 16

[Wesley Johnston (:wesj)]

Attachment: Testcase

Sure! There's a testcase listed a few comments up, but I'm uploading it here. Essentially, the canvas should turn green when you tap it. Currently, that will work on the left hand side, but not the right.

As best I can decipher, the flow moves something like this. We dispatch the events from Java (currently) transformed into the coordinates of the current tabs displayport:

http://mxr.mozilla.org/mozilla-aurora/source/mobile/android/base/GeckoEvent.java#237

I want to remove this and instead send them in the units display pixels. They bubble through Gecko and in nsPresShell, we convert them to App units:

http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#5961
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp#995

before sending them off to build a display list for items within a 1x1 rect at that point. At that point, I have a sketchier understanding of what goes on, but it looks like we keep everything in AppUnits. I'm told that means we don't need to do any other conversions? That doesn't seem right to me.

The logging of the DisplayList above is from tapping on the left side of the box, and shows an outer clipping rect with an area of 28800x44640 while the inner one has an area of 58800x91140. I assume that outer rect is the browser element and the inner one is the content inside it. If the user taps (in App units) at 30000,50000, their tap is clipped by the clip rect above?

If I remove the code in Java that scales the touch coordinates, we essentially can't send a touch point at 30000,50000 (i.e. its outside the screen bounds, so we need to scale the point as we move through the display list, or scale the rects we're comparing to). The only time I see presShell:mXResolution or presShell:mYResolution used are during PaintFrame though. (i.e. we do the scaling while drawing, but not while building displaylists?).

Comment 17

[Wesley Johnston (:wesj)]

I've been trying to hack detection and applying DisplayPort into nsIFrame::IsTransformed and nsIFrame::GetTransformMatrix. Not sure if thats the right thing to do?

To do that I'm also having to dig through some presShell issues. i.e. not sure we can just check if this particular frame has a displayport set on it. I know for instance the the displayport and resolution are not set on the same frame.

Comment 18

[Ming-Yee Iu]

I don't know anything about the internals of Gecko, so I don't know if this helps, but I noticed that if you have an image sitting on the right side of the screen, touching the image will not trigger any touch events to the document, but it will cause a menu to pop up allowing you to save the image elsewhere. So the touch events are caught, recognized, and mapped correctly to elements, but are not being routed to the touch handlers properly. Perhaps you could hook the "save image" menu in a debugger and see the route it takes to get there.

e.g. this causes problems on my nexus s:

<div style="width: 800px; height: 300px; position: relative; background-color: green;">
<div style="right: 0px; top: 0px; width: 100px; height: 100px; position: absolute; overflow: hidden;"><img src="PUT AN IMAGE HERE"></div>
</div>

<div id="debug"></div>
<script>
function touch(evt)
{
	if (evt.touches.length > 0)
		document.getElementById('debug').innerHTML = 'x: ' + evt.touches[0].pageX 
			+ ' y: ' + evt.touches[0].pageY;
	evt.preventDefault();
	return false;
}

document.ontouchstart = touch;
document.ontouchmove = touch;
document.ontouchend = touch;
</script>

Comment 19

[Wesley Johnston (:wesj)]

Yeah. Mouse events are dispatched using DOMWindowUtils.sendMouseEventToWindow, which allows them to sidestep being clipped by the browser presContext (because by passing a window, we give an explicit presShell for them to use). Context menus actually use window.elementFromPoint with coordinates that (again) were already transformed in Java, again bypassing this problem.

XUL Fennec stepped around it (AFAICT) by using e10s. The only pages allowed to use display port there were e10s documents, and as such they skipped this cross-document displayport issue.

Comment 20

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

tn, can you offer some guidance?

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Appunits are always based on CSS pixels (60 appunits per CSS pixel).

Is it only touch events that are a problem here? Mouse events are OK?

Comment 22

[Chris Lord [:cwiiis]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #21)
> Appunits are always based on CSS pixels (60 appunits per CSS pixel).
> 
> Is it only touch events that are a problem here? Mouse events are OK?

Correct, I think - only touch events are affected.

Comment 23

[Wesley Johnston (:wesj)]

> Is it only touch events that are a problem here? Mouse events are OK?

Because of the way we send mouse events in Fennec right now (we find a target nearby your finger and dispatch the event to it using DOMWindowUtils.sendMouseEventToWindow from browser.js), we don't see this with them. However, if we did send them through widget they have this same problem.

Comment 24

[JP Rosevear [:jpr]]

Matt, do you have some ideas here?

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This really shouldn't be that hard to figure out. What is the size of the <browser> element in the mobile chrome document? It's apparently not as big as the screen. Fix that.

Comment 26

[Wesley Johnston (:wesj)]

AFAICT, the browser element is the size of the screen. The page is layed out larger than the screen, then scaled when we draw it. I am mostly picking my way through this learning as I go though. If I misunderstood our code, someone please correct me.

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What causes this scaling? Are we using RenderFrameParent to add extra transforms when compositing shadow layers?

Comment 28

[Wesley Johnston (:wesj)]

Attachment: Early WIP patch

This basically just adjusts our coordinates when looking at a scrollframe with a displayport set. Seems to fix touch events on my simple simple simple page. Breaks many other things, I think probably because this transform isn't right, so I'm playing with it.

Not sure if this is an ok fix or not?

Comment 29

[Wesley Johnston (:wesj)]

Obviously not this patch I mean. I'll have to apply similar transforms when calculating screeX/Y, pageX/Y, etc.

Comment 30

[Kevin Brosnan [Ex-Mozilla]]

http://www.slideshare.net/lhawthorn/lca-final-11148160

Another site that may be affected by this. Talked with Wes today and we thing that the touch events on this site are hard to trigger when swiping to from the right to the left.

Comment 31

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

Comment on attachment 616335 [details] [diff] [review]
Early WIP patch

>             PointF geckoPoint = new PointF(event.getX(eventIndex), event.getY(eventIndex));
>-            geckoPoint = GeckoApp.mAppContext.getLayerController().convertViewPointToLayerPoint(geckoPoint);
>+            //geckoPoint = GeckoApp.mAppContext.getLayerController().convertViewPointToLayerPoint(geckoPoint);
>     

I don't know about the rest of the patch, but I like the look of this... this means the touch events are no longer viewport-dependent and so we'll be able to coalesce them across viewport events in nsAppShell.

Comment 32

[Wesley Johnston (:wesj)]

Attachment: More Early WIP

More WIP work. This allows double tap zoom to work by also applying the current display port transform to the dirtyRect when calling hitTest. Still need to work out that transform better (currently changes our hit detection rect to be 0 width if the scale > 1), and probably optimize when its done(?) as well as fix the coordinates of the events (I guess we'll transform them into the resolution of the target's owner document?). Oh yeah, and this breaks drawing sometimes. aka. lots to do, but getting better.

Comment 33

[Wesley Johnston (:wesj)]

Attachment: Hacky Patch

OK, this is a hacky run around the end way of fixing this that fixes my test page at:

http://dl.dropbox.com/u/72157/irish.html

(i.e. tapping on the canvases turns them green and shows appropriate messages in the console). It works by dispatching to the active tabs presShell rather than the root document's one. Events will still bubble up to the root document. Unfortunately, this doesn't fix the Paul Irish demo at:

http://paulirish.com/demo/multi

which sets a metaviewport with content="width=device-width, initial-scale=1.0" on a page that is much wider than the screen. Not sure why he does this, but heck, its the mobile web. We're essentially writing Quirks mode 2.0 here. Similar change to my page at:

http://dl.dropbox.com/u/72157/irishviewport.html

I think the issue there is that we are now skipping looking at browser.xul, but also size our browser element to 320px wide and then setting the CSSViewport + scaling the content inside it. That's (again) killing off touches that are outside that 320px wide browser element?

This seems like an odder edge case. I can look into changing how we do our scaling to avoid this, but I think we're better to fix this correctly (for 2.0?), and potentially take this hacky fix for 1.0.

Comment 34

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 618227 [details] [diff] [review]
Hacky Patch

So you want to target to the first active content shell?
The re-targeting should probably go to
PresShell::HandleEvent, where we do other kind of re-targeting too.

Is there really no way to do the thing somewhere in Fennec / Android-widget?
Or is the problem that chrome shell has different scaling than
content shell? But why does event handling work in Firefox in that case?
I think roc or tn should give some feedback here.
I'm not familiar enough with Native Fennec's architecture.

Comment 35

[Wesley Johnston (:wesj)]

Attachment: Hacky Patch v2

Comment 36

[Wesley Johnston (:wesj)]

Attachment: WIP Real patch

I'm just putting this guy up to save my place. Touch events seem to work with it. Mouse events (which we dispatch differently) are not finding the correct targets. For now, I was looking to alter this so that if the caller passed in IgnoreRootScrollFrame, we would assume the event coordinates it sent were also in the units of the document we are looking at. Otherwise they would be scaled to the correct resolution. That means nsIFrame::HitTest also needs to know what to do, which meant adjusting a lot of callers.

tn, if you have any time to look this over, even though its pretty early and rough, can you give me any feedback on whether or not this will (generally) work?, or if you know of better ways to do it?

Comment 37

[Timothy Nikkel (:tnikkel)]

Comment on attachment 618371 [details] [diff] [review]
WIP Real patch

I think it would be cleaner to add a flag to nsDisplayListBuilder instead of adding an argument to HitTest. Speaking of which it already has a SetIgnoreScrollFrame function, can we just use that? Or does this have a different meaning?

Comment 38

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 618363 [details] [diff] [review]
Hacky Patch v2

Actually, if we take this approach as a quick hack, 
could you take the docshell using
nsIDocShellTreeOwner::primaryContentShell
Should be simpler than enumerator.

Comment 39

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 618371 [details] [diff] [review]
WIP Real patch

Review of attachment 618371 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/base/nsLayoutUtils.h
@@ +93,5 @@
>  
> +  static nsRect AdjustPointForDisplayport(const nsRect &aRect,
> +                                          nsIFrame *aFrame,
> +                                          bool useRootScrollframe,
> +                                          int mode);

definitely needs to be documented!!!

aUseRootScrollFrame, aMode

::: layout/generic/nsGfxScrollFrame.cpp
@@ +2200,3 @@
>    if (usingDisplayport) {
> +    if (!aBuilder->IsForEventDelivery())
> +      dirtyRect = displayPort;

reverse the order of clauses to avoid !, and put {} around the if/else bodies

@@ +2200,5 @@
>    if (usingDisplayport) {
> +    if (!aBuilder->IsForEventDelivery())
> +      dirtyRect = displayPort;
> +    else
> +      dirtyRect = nsLayoutUtils::AdjustPointForDisplayport(dirtyRect, mOuter, true, 1);

I'm not sure why we're converting between coordinate systems here. It seems to me we should be converting them further up the stack, if conversion is necessary. If we need to adjust for the displayport then the coordinates must have been wrong to start with.

Comment 40

[Wesley Johnston (:wesj)]

Attachment: Hacky Patch v3

OK. I tried for awhile adding a method to DOMWindowUtils that let us set a toucheventtarget on the root windows presShell. After crashing for a bit, I've come back to this solution in the name of speed.

This uses GetPrimaryContentShell to get the active tab and returns its nsIDocument. It also hooks into some code we already had for (in some cases) redirecting mouse events to a different presShell.

Comment 41

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 618795 [details] [diff] [review]
Hacky Patch v3

># HG changeset patch
># Parent 43da2bae5aa1bad968258f22b61cacedbba6fa3c
># User Wes Johnston <[e-mail]>
>diff --git a/layout/base/nsPresShell.cpp b/layout/base/nsPresShell.cpp
>--- a/layout/base/nsPresShell.cpp
>+++ b/layout/base/nsPresShell.cpp
>@@ -5787,16 +5787,20 @@ PresShell::HandleEvent(nsIFrame        *
> 
>       retargetEventDoc = do_QueryInterface(window->GetExtantDocument());
>       if (!retargetEventDoc)
>         return NS_OK;
>     } else if (capturingContent) {
>       // if the mouse is being captured then retarget the mouse event at the
>       // document that is being captured.
>       retargetEventDoc = capturingContent->GetCurrentDoc();
>+#ifdef ANDROID
>+    } else if (aEvent->eventStructType == NS_TOUCH_EVENT) {
>+      retargetEventDoc = GetTouchEventTargetDocument();
>+#endif
>     }
> 
>     if (retargetEventDoc) {
>       nsCOMPtr<nsIPresShell> presShell = retargetEventDoc->GetShell();
>       if (!presShell)
>         return NS_OK;
> 
>       if (presShell != this) {
>@@ -6188,16 +6192,66 @@ PresShell::HandleEvent(nsIFrame        *
>       // Retarget them -- the parent chrome shell might make use of them.
>       return RetargetEventToParent(aEvent, aEventStatus);
>     }
>   }
> 
>   return rv;
> }
> 
>+#ifdef ANDROID
>+nsIDocument*
>+PresShell::GetTouchEventTargetDocument() {
{ should be in the next line


>+  nsPresContext* context = GetPresContext();
>+  if (!context || !context->IsRoot())
>+    return nsnull;
if (expr) {
  stmt;
}
Same also elsewhere.


>+
>+  // get our doc shell tree owner
A bit strange comment, syntactically. Perhaps just remove it.

>+  nsCOMPtr<nsISupports> container = context->GetContainer();
>+  if (!container)
>+    return nsnull;
>+  nsCOMPtr<nsIDocShell> docShell(do_QueryInterface(container));
do_* macros are null-safe, so no need to null-check container.


>+  if (!docShell)
>+    return nsnull;
nor docShell


>+
>+  nsCOMPtr<nsIDocShellTreeItem> shellAsTreeItem = do_QueryInterface(docShell);
>+  if (!shellAsTreeItem)
>+    return nsnull;
Hmm, why do you need to first Qi to docshell and then to docshelltreeitem?
QIing from container to docshelltreeitem should be enough.



>+
>+  nsCOMPtr<nsIDocShellTreeOwner> owner;
>+  shellAsTreeItem->GetTreeOwner(getter_AddRefs(owner));
>+  if (!owner)
>+    return nsnull;
>+
>+  // now get the primary content shell (active tab)
>+  nsCOMPtr<nsIDocShellTreeItem> item;
>+  owner->GetPrimaryContentShell(getter_AddRefs(item));
>+  if (!item)
>+    return nsnull;
>+
>+  nsCOMPtr<nsIDocShell> childDocShell = do_QueryInterface(item);
>+  if (!childDocShell)
>+    return nsnull;
>+
>+  // get the nsIDocument associate with the active tab

nsCOMPtr<nsIDocument> result = do_GetInterface(childDocShell);
return result;
should be enough

Comment 42

[Wesley Johnston (:wesj)]

Attachment: Hacky Patch v4

Comment 43

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 618805 [details] [diff] [review]
Hacky Patch v4


>+  // now get the primary content shell (active tab)
>+  nsCOMPtr<nsIDocShellTreeItem> item;
>+  owner->GetPrimaryContentShell(getter_AddRefs(item));
>+  nsCOMPtr<nsIDocShell> childDocShell = do_QueryInterface(item);
>+  if (!childDocShell) {
>+    return nsnull;
>+  }
>+
>+  nsCOMPtr<nsIDocument> result = do_GetInterface(childDocShell);
No need to null check childDocShell

Comment 44

[Wesley Johnston (:wesj)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/ed70c068e4ef

DO NOT close this bug when this lands. This patch is a band-aid while I work on the real one.

Comment 45

[Wesley Johnston (:wesj)]

http://hg.mozilla.org/releases/mozilla-aurora/rev/3c87865c60ab

Comment 46

[Wesley Johnston (:wesj)]

Split off real fix to bug 749481.

Comment 47

[Matt Brubeck (:mbrubeck)]

This should be resolved when it's merged from inbound to m-c.

Comment 48

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/ed70c068e4ef

Comment 49

[Adrian Tamas (:AdrianT)]

On Nightly 15.0a1 2012-04-30/Aurora 14.0a2 2012-04-29 on Motorola Droid Pro(Android 2.3.4) I am seeing the crash https://crash-stats.mozilla.com/report/index/bp-88a0d24d-61da-4c16-9db6-ba4822120430 when loading http://games.user00.com/EndlessRoad/index.html

For http://paulirish.com/demo/multi i can draw the lines without any issues on the right side of the view at a high zoom level. http://dl.dropbox.com/u/72157/irish.html and http://dl.dropbox.com/u/72157/irishviewport.html also work.

Closing this as verified as the other work on this will be tracked in Bug 749481.

Verified on:
Nightly 15.0a1 2012-04-30
Aurora 14.0a2 2012-04-29
Device: Motorola Droid Pro
OS: Android 2.3.4

Comment 50

[Wesley Johnston (:wesj)]

Comment on attachment 618371 [details] [diff] [review]
WIP Real patch

Moved this to bug 749481.