Closed Bug 1036264 Opened 10 years ago Closed 10 years ago

[dolphin][flame] "save image" only appears when user taping on the top left after zooming out a picture

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Platform:
All
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla34
Project Flags:
blocking-b2g 1.4+
Tracking Flags:
Tracking Status
firefox32 --- wontfix
firefox33 --- wontfix
firefox34 --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: angelc04, Assigned: kanru)

Details

(Whiteboard: [sprd330255][partner-blocker])

Attachments

(2 files, 3 obsolete files)

Always pass true for ignoreRootScrollFrame
2.63 KB, patch
kats
: review+
Details | Diff | Splinter Review
video
3.09 MB, video/mp4
Details 
Steps to reproduce
--------------------------------------------------------------------
1. Launch browser
2. in the address bar input "http://d.3987.com/bxsj_131030/003.jpg"
3. The picture will be displayed in original size
4. Long tap on any position on this picture, you will see "Save Image" menu appears
5. Zoom out the picture to the minimum size
6. Long tap on any position except the top left corner
   --> The "Save Image" menu does not show up.

Note:
- This could be reproduced on both flame and dolphin.
- This is specific to some large picture which can be zoomed out.
Whiteboard: [sprd330255]
Hi Evelyn,Could you please help with this? Thanks !
Flags: needinfo?(ehung)
Hi! Peter,

Per our discussion, this could be a layout issue.
NI you first. Thanks

--
Keven
Flags: needinfo?(ehung) → needinfo?(pchang)
Debugging from Gaia side, I found browser app can get a contextmenu event while the image is long pressed. However, the `evt.detail.systemTargets` is empty. It should include a 'IMG' tag in a normal case.
(In reply to Evelyn Hung [:evelyn] from comment #3)
> Debugging from Gaia side, I found browser app can get a contextmenu event
> while the image is long pressed. However, the `evt.detail.systemTargets` is
> empty. It should include a 'IMG' tag in a normal case.

so inserting a log in http://mxr.mozilla.org/mozilla-b2g30_v1_4/source/dom/browser-element/BrowserElementChildPreload.js#648 to print |e.target|, and it shows we are long pressing a |ImageDocument|, not a |HTMLImageElement|. Not sure the difference between them.

I/Gecko   (  918): BrowserElementChildPreload - Got contextmenu on element [object XrayWrapper [object ImageDocument]]
BTW, I can reproduce this issue on Flame, too.
blocking-b2g: --- → 1.4?
Whiteboard: [sprd330255] → [sprd330255][partner-blocker]
From layout side, we always treat this image as image frame. Therefore, I think this issue is related to dom element handling, not related to layout.

I/Gecko   (17986):     AbsoluteList b25ff460 <
I/Gecko   (17986):       ImageFrame(img)(0)@b2aaf820 {0,0,115200,64800} [state=0000004000200110] [content=b1358080] [sc=b2a524a8,parent=b2a51aa0] [src=http://d.3987.com/bxsj_131030/003.jpg]
I/Gecko   (17986):     >
Flags: needinfo?(pchang)
ImageDocument is the document type created for image url. The document creates a synthesized dom tree which should be very simple, for example:

    <html>
        <head>
            <meta name="viewport" content="width=device-width; height=device-height;"></meta>
            <link rel="stylesheet" href="resource://gre/res/ImageDocument.css"></link>
            <link rel="stylesheet" href="resource://gre/res/TopLevelImageDocument.css"></link>
            <link rel="stylesheet" href="chrome://global/skin/media/TopLevelImageDocument.css"></link>
            <title>
                test.jpg (JPEG Image, 2048 × 1360 pixels) - Scaled…
            </title>
        </head>
        <body>
            <img class="shrinkToFit decoded" width="819" height="544"
                 src="file:///home/kanru/test.jpg" alt="file:///home/kanru/test.jpg"></img>
        </body>
    </html>

Normally the contextmenu event should be dispatched to elements but in this case it's dispatched to the document. Maybe it's that we are listening a system event and APZC send it to weird place so we only received the event dispatched to document. 

http://hg.mozilla.org/mozilla-central/file/330ba968ed61/dom/ipc/TabChild.cpp#l1833
(In reply to Kan-Ru Chen [:kanru] from comment #7)
> ImageDocument is the document type created for image url. The document
> creates a synthesized dom tree which should be very simple, for example:
> 
>     <html>
>         <head>
>             <meta name="viewport" content="width=device-width;
> height=device-height;"></meta>
>             <link rel="stylesheet"
> href="resource://gre/res/ImageDocument.css"></link>
>             <link rel="stylesheet"
> href="resource://gre/res/TopLevelImageDocument.css"></link>
>             <link rel="stylesheet"
> href="chrome://global/skin/media/TopLevelImageDocument.css"></link>
>             <title>
>                 test.jpg (JPEG Image, 2048 × 1360 pixels) - Scaled…
>             </title>
>         </head>
>         <body>
>             <img class="shrinkToFit decoded" width="819" height="544"
>                  src="file:///home/kanru/test.jpg"
> alt="file:///home/kanru/test.jpg"></img>
>         </body>
>     </html>
> 
> Normally the contextmenu event should be dispatched to elements but in this
> case it's dispatched to the document. Maybe it's that we are listening a
> system event and APZC send it to weird place so we only received the event
> dispatched to document. 
> 
> http://hg.mozilla.org/mozilla-central/file/330ba968ed61/dom/ipc/TabChild.
> cpp#l1833

I checked the codes, but I don't have clear view on this. Kan-Ru, so, do you have any suggested solution? Thank you.
Flags: needinfo?(kchen)
The BackgroundColor and WrapList have weird bounds.

BackgroundColor 43de2b28(HTMLScroll(html)(-1)) bounds(0,0,19200,21900) visible(0,0,0,0) componentAlpha(0,0,0,0) clip()  uniform (rgba 0,0,0,0)
CanvasBackgroundColor 43de2938(Canvas(html)(-1)) bounds(0,0,115200,64800) visible(0,0,0,0) componentAlpha(0,0,0,0) clip(0,0,19200,21900)  uniform layer=4035f800
CanvasBackgroundImage 43de2938(Canvas(html)(-1)) bounds(0,0,115200,64800) visible(0,0,0,0) componentAlpha(0,0,0,0) clip(0,0,19200,21900)  (opaque 0,0,19200,21900) layer=4035f800
BackgroundColor 43f0a320(Block(html)(-1)) bounds(0,0,19200,0) visible(0,0,0,0) componentAlpha(0,0,0,0) clip(0,0,19200,21900)  uniform (rgba 0,0,0,0)
BackgroundColor 43f0a710(Block(body)(1)) bounds(0,0,19200,0) visible(0,0,0,0) componentAlpha(0,0,0,0) clip(0,0,19200,21900)  uniform (rgba 0,0,0,0)
WrapList 4358f240(ImageFrame(img)(0)) bounds(0,0,19200,21900) visible(0,0,0,0) componentAlpha(0,0,0,0) clip() 
  BackgroundColor 4358f240(ImageFrame(img)(0)) bounds(0,0,115200,64800) visible(0,0,0,0) componentAlpha(0,0,0,0) clip(0,0,19200,21900)  uniform (opaque 0,0,115200,64800) (rgba 229,229,229,255) layer=4035f800
  Background 4358f240(ImageFrame(img)(0)) bounds(0,0,115200,64800) visible(0,0,0,0) componentAlpha(0,0,0,0) clip(0,0,19200,21900)  layer=4035f800
  Image 4358f240(ImageFrame(img)(0)) bounds(0,0,115200,64800) visible(0,0,0,0) componentAlpha(0,0,0,0) clip(0,0,19200,21900)  layer=4035f800
Kats and Matt, the DisplayList in comment 9 is a a ImageDocument with initial viewport 320x365 then unzoomed.

I'm not sure if the HTMLScroll frame should change it's bounds when unzoomed, but the smaller than screen bounds prevents event dispatch. Any ideas?
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(kchen)
Flags: needinfo?(bugmail.mozilla)
Initial mLastRootMetrics

(gdb) p mLastRootMetrics 
$15 = {
  static NULL_SCROLL_ID = 0, 
  static START_SCROLL_ID = <optimized out>, 
  mCompositionBounds = {
    <mozilla::gfx::BaseRect<int, mozilla::gfx::IntRectTyped<mozilla::ParentLayerPixel>, mozilla::gfx::IntPointTyped<mozilla::ParentLayerPixel>, mozilla::gfx::IntSizeTyped<mozilla::ParentLayerPixel>, mozilla::gfx::IntMarginTyped<mozilla::ParentLayerPixel> >> = {
      x = 0, 
      y = 0, 
      width = 320, 
      height = 365
    }, 
    <mozilla::ParentLayerPixel> = {<No data fields>}, <No data fields>}, 
  mDisplayPort = {
    <mozilla::gfx::BaseRect<float, mozilla::gfx::RectTyped<mozilla::CSSPixel>, mozilla::gfx::PointTyped<mozilla::CSSPixel>, mozilla::gfx::SizeTyped<mozilla::CSSPixel>, mozilla::gfx::MarginTyped<mozilla::CSSPixel> >> = {
      x = 0, 
      y = 0, 
      width = 1920, 
      height = 1080
    }, 
    <mozilla::CSSPixel> = {<No data fields>}, <No data fields>}, 
  mCriticalDisplayPort = {
    <mozilla::gfx::BaseRect<float, mozilla::gfx::RectTyped<mozilla::CSSPixel>, mozilla::gfx::PointTyped<mozilla::CSSPixel>, mozilla::gfx::SizeTyped<mozilla::CSSPixel>, mozilla::gfx::MarginTyped<mozilla::CSSPixel> >> = {
      x = 0, 
      y = 0, 
      width = 0, 
      height = 0
    }, 
    <mozilla::CSSPixel> = {<No data fields>}, <No data fields>}, 
  mViewport = {
    <mozilla::gfx::BaseRect<float, mozilla::gfx::RectTyped<mozilla::CSSPixel>, mozilla::gfx::PointTyped<mozilla::CSSPixel>, mozilla::gfx::SizeTyped<mozilla::CSSPixel>, mozilla::gfx::MarginTyped<mozilla::CSSPixel> >> = {
      x = 0, 
      y = 0, 
      width = 320, 
      height = 365
    }, 
    <mozilla::CSSPixel> = {<No data fields>}, <No data fields>}, 
  mScrollId = 4, 
  mScrollableRect = {
    <mozilla::gfx::BaseRect<float, mozilla::gfx::RectTyped<mozilla::CSSPixel>, mozilla::gfx::PointTyped<mozilla::CSSPixel>, mozilla::gfx::SizeTyped<mozilla::CSSPixel>, mozilla::gfx::MarginTyped<mozilla::CSSPixel> >> = {
      x = 0, 
      y = 0, 
      width = 1920, 
      height = 1080
    }, 
    <mozilla::CSSPixel> = {<No data fields>}, <No data fields>}, 
  mResolution = {
    scale = 1
  }, 
  mCumulativeResolution = {
    scale = 1
  }, 
  mTransformScale = {
    scale = 1
  }, 
  mDevPixelsPerCSSPixel = {
    scale = 1
  }, 
  mPresShellId = 4, 
  mMayHaveTouchListeners = false, 
  mIsRoot = true, 
  mHasScrollgrab = false, 
  mScrollOffset = {
    <mozilla::gfx::BasePoint<float, mozilla::gfx::PointTyped<mozilla::CSSPixel> >> = {
      x = 0, 
      y = 0
    }, 
    <mozilla::CSSPixel> = {<No data fields>}, <No data fields>}, 
  mZoom = {
    scale = 1
  }, 
  mUpdateScrollOffset = false, 
  mScrollGeneration = 0, 
  mContentDescription = {
    <std::priv::_String_base<char, std::allocator<char> >> = {
      _M_buffers = {
        _M_end_of_storage = 0x5a5a5a00 <Address 0x5a5a5a00 out of bounds>, 
        _M_static_buf = "\000", 'Z' <repeats 15 times>
      }, 
      _M_finish = 0x4355b864 "", 
      _M_start_of_storage = {
        <std::allocator<char>> = {
          <std::__stlport_class<std::allocator<char> >> = {<No data fields>}, <No data fields>}, 
        members of std::priv::_STLP_alloc_proxy<char*, char, std::allocator<char> >: 
        _M_data = 0x4355b864 ""
      }
    }, 
    members of std::basic_string<char, std::char_traits<char>, std::allocator<char> >: 
    static npos = <optimized out>
  }, 
  mRootCompositionSize = {
    <mozilla::gfx::BaseSize<float, mozilla::gfx::SizeTyped<mozilla::CSSPixel> >> = {
      width = 320, 
      height = 365
    }, 
    <mozilla::CSSPixel> = {<No data fields>}, <No data fields>}, 
  mDisplayPortMargins = {
    <mozilla::gfx::BaseMargin<float, mozilla::gfx::MarginTyped<mozilla::LayerPixel> >> = {
      top = -0, 
      right = 640, 
      bottom = 715, 
      left = -0
    }, 
    <mozilla::LayerPixel> = {<No data fields>}, <No data fields>}, 
  mUseDisplayPortMargins = true
}
Unzoomed

(gdb) p mLastRootMetrics 
$16 = {
  static NULL_SCROLL_ID = 0, 
  static START_SCROLL_ID = <optimized out>, 
  mCompositionBounds = {
    <mozilla::gfx::BaseRect<int, mozilla::gfx::IntRectTyped<mozilla::ParentLayerPixel>, mozilla::gfx::IntPointTyped<mozilla::ParentLayerPixel>, mozilla::gfx::IntSizeTyped<mozilla::ParentLayerPixel>, mozilla::gfx::IntMarginTyped<mozilla::ParentLayerPixel> >> = {
      x = 0, 
      y = 0, 
      width = 320, 
      height = 365
    }, 
    <mozilla::ParentLayerPixel> = {<No data fields>}, <No data fields>}, 
  mDisplayPort = {
    <mozilla::gfx::BaseRect<float, mozilla::gfx::RectTyped<mozilla::CSSPixel>, mozilla::gfx::PointTyped<mozilla::CSSPixel>, mozilla::gfx::SizeTyped<mozilla::CSSPixel>, mozilla::gfx::MarginTyped<mozilla::CSSPixel> >> = {
      x = 0, 
      y = 0, 
      width = 1024, 
      height = 1080
    }, 
    <mozilla::CSSPixel> = {<No data fields>}, <No data fields>}, 
  mCriticalDisplayPort = {
    <mozilla::gfx::BaseRect<float, mozilla::gfx::RectTyped<mozilla::CSSPixel>, mozilla::gfx::PointTyped<mozilla::CSSPixel>, mozilla::gfx::SizeTyped<mozilla::CSSPixel>, mozilla::gfx::MarginTyped<mozilla::CSSPixel> >> = {
      x = 0, 
      y = 0, 
      width = 0, 
      height = 0
    }, 
    <mozilla::CSSPixel> = {<No data fields>}, <No data fields>}, 
  mViewport = {
    <mozilla::gfx::BaseRect<float, mozilla::gfx::RectTyped<mozilla::CSSPixel>, mozilla::gfx::PointTyped<mozilla::CSSPixel>, mozilla::gfx::SizeTyped<mozilla::CSSPixel>, mozilla::gfx::MarginTyped<mozilla::CSSPixel> >> = {
      x = 0, 
      y = 0, 
      width = 320, 
      height = 365
    }, 
    <mozilla::CSSPixel> = {<No data fields>}, <No data fields>}, 
  mScrollId = 4, 
  mScrollableRect = {
    <mozilla::gfx::BaseRect<float, mozilla::gfx::RectTyped<mozilla::CSSPixel>, mozilla::gfx::PointTyped<mozilla::CSSPixel>, mozilla::gfx::SizeTyped<mozilla::CSSPixel>, mozilla::gfx::MarginTyped<mozilla::CSSPixel> >> = {
      x = 0, 
      y = 0, 
      width = 1920, 
      height = 1080
    }, 
    <mozilla::CSSPixel> = {<No data fields>}, <No data fields>}, 
  mResolution = {
    scale = 0.337962955
  }, 
  mCumulativeResolution = {
    scale = 0.337962955
  }, 
  mTransformScale = {
    scale = 1
  }, 
  mDevPixelsPerCSSPixel = {
    scale = 1
  }, 
  mPresShellId = 5, 
  mMayHaveTouchListeners = false, 
  mIsRoot = true, 
  mHasScrollgrab = false, 
  mScrollOffset = {
    <mozilla::gfx::BasePoint<float, mozilla::gfx::PointTyped<mozilla::CSSPixel> >> = {
      x = 0, 
      y = 0
    }, 
    <mozilla::CSSPixel> = {<No data fields>}, <No data fields>}, 
  mZoom = {
    scale = 0.337962955
  }, 
  mUpdateScrollOffset = false, 
  mScrollGeneration = 0, 
  mContentDescription = {
    <std::priv::_String_base<char, std::allocator<char> >> = {
      _M_buffers = {
        _M_end_of_storage = 0x5a5a5a00 <Address 0x5a5a5a00 out of bounds>, 
        _M_static_buf = "\000", 'Z' <repeats 15 times>
      }, 
      _M_finish = 0x4355b864 "", 
      _M_start_of_storage = {
        <std::allocator<char>> = {
          <std::__stlport_class<std::allocator<char> >> = {<No data fields>}, <No data fields>}, 
        members of std::priv::_STLP_alloc_proxy<char*, char, std::allocator<char> >: 
        _M_data = 0x4355b864 ""
      }
    }, 
    members of std::basic_string<char, std::char_traits<char>, std::allocator<char> >: 
    static npos = <optimized out>
  }, 
  mRootCompositionSize = {
    <mozilla::gfx::BaseSize<float, mozilla::gfx::SizeTyped<mozilla::CSSPixel> >> = {
      width = 946.849365, 
      height = 1080
    }, 
    <mozilla::CSSPixel> = {<No data fields>}, <No data fields>}, 
  mDisplayPortMargins = {
    <mozilla::gfx::BaseMargin<float, mozilla::gfx::MarginTyped<mozilla::LayerPixel> >> = {
      top = 0, 
      right = 328.888855, 
      bottom = 0, 
      left = -0
    }, 
    <mozilla::LayerPixel> = {<No data fields>}, <No data fields>}, 
  mUseDisplayPortMargins = true
}
This is 1.4 blocker according to its symptom.
blocking-b2g: 1.4? → 1.4+
The metrics look fine except for the mRootCompositionSize - that gets larger after unzooming which doesn't make sense.

I don't think the display list should change much either when zooming out. In this case the displaylist just should be the entire image/document always, and the dimensions in app units or layout pixels should be the same before and after the change in zoom. It's just the resolution that changes.

It sounds like the long-tap touch events are getting to the correct APZC instance and getting to TabChild ok, it's just that they end up with the wrong target element. My best guess is that because we set the ignoreRootScrollFrame argument to false at [1], the Gecko hit testing thinks the long-tap (in CSS coordinates) is happening outside the root scroll frame and doesn't find the image element. If you flip that argument to true it might fix the problem.

[1] http://mxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.cpp?rev=568b73c5bd31#1838
Flags: needinfo?(bugmail.mozilla)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #14)
> The metrics look fine except for the mRootCompositionSize - that gets larger
> after unzooming which doesn't make sense.
> 
> I don't think the display list should change much either when zooming out.
> In this case the displaylist just should be the entire image/document
> always, and the dimensions in app units or layout pixels should be the same
> before and after the change in zoom. It's just the resolution that changes.
> 
> It sounds like the long-tap touch events are getting to the correct APZC
> instance and getting to TabChild ok, it's just that they end up with the
> wrong target element. My best guess is that because we set the
> ignoreRootScrollFrame argument to false at [1], the Gecko hit testing thinks
> the long-tap (in CSS coordinates) is happening outside the root scroll frame
> and doesn't find the image element. If you flip that argument to true it
> might fix the problem.
> 
> [1]
> http://mxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.
> cpp?rev=568b73c5bd31#1838

Indeed changing ignoreRootScrollFrame to true fixed the problem. However, I don't know if this is a correct fix. What was problem the ignoreRootScrollFrame flag invented for?
I made a test case here that shows that even normal touch event has the same problem:

http://people.mozilla.org/~kchen/1036264.html

Load the page in browser then try to click the green square. If the page is zoomed out then the green square can't receive the "click" event.

So I think we have to change all the ignoreRootScrollFrame flags to true?
Assignee: nobody → kchen
Attached patch Tentative patch (obsolete) — — Splinter Review 
With this patch the contextmenu is fixed.
But in my test page the green square could only receive "touchend" but not "click" event.
Attached image 2014-07-24-16-52-49.png (obsolete) — 
While testing my test page on the phone, I found that when zooming out, the scroll bar is still at the old position.

I think this is related. The root scroll frame is not updated so the scrollbar sticks to the old size and position. Maybe we should enlarge the root scroll frame when zooming out instead of change the ignoreRootScrollFrame flag?
Flags: needinfo?(bugmail.mozilla)
Change component to Core :: GFX :: Layers as I think this is related to APZ..
Component: Gaia::Browser → Graphics: Layers
Product: Firefox OS → Core
(In reply to Kan-Ru Chen [:kanru] from comment #16)
> I made a test case here that shows that even normal touch event has the same
> problem:
> 
> http://people.mozilla.org/~kchen/1036264.html
> 
> Load the page in browser then try to click the green square. If the page is
> zoomed out then the green square can't receive the "click" event.
> 
> So I think we have to change all the ignoreRootScrollFrame flags to true?

Hmm... actually the "touchend" event works on a nightly built Flame.
(In reply to Kan-Ru Chen [:kanru] from comment #15)
> Indeed changing ignoreRootScrollFrame to true fixed the problem. However, I
> don't know if this is a correct fix. What was problem the
> ignoreRootScrollFrame flag invented for?

I'm not 100% sure, but I think the quick explanation is there are parts of gecko that don't pay attention to displayports. Hit testing for events is one of these parts. In theory if you click anywhere inside the displayport it should get dispatched to the element you clicked on. However the hit testing code for events which goes through [1] doesn't do that, it still uses the CSS viewport (i.e. the size of the root scroll frame) as the clipping rect for finding event hit targets. At least that's the case for mouse events, I guess touch events are different. I don't know the full details here. I know that in Fennec whenever we used DOM APIs like DOMWindowUtils.elementFromPoint we always need to pass true for ignoreRootScrollFrame or it would have this same problem. Anyway, the flag makes it ignore the clipping applied from the CSS viewport and so allows dispatching to the full document.

(In reply to Kan-Ru Chen [:kanru] from comment #16)
> I made a test case here that shows that even normal touch event has the same
> problem:
> 
> http://people.mozilla.org/~kchen/1036264.html
> 
> Load the page in browser then try to click the green square. If the page is
> zoomed out then the green square can't receive the "click" event.
> 
> So I think we have to change all the ignoreRootScrollFrame flags to true?

Was this always the case? I don't think anything has changed in this regard recently, but if it's not a recent regression then I'm very surprised nobody has noticed until now. It might be worth quickly checking a 1.3/1.4/2.0 build to see if it happens there as well. I know the scrollbars were only enabled recently (bug 995519) and the behaviour you're seeing there is definitely a regression. Please file a new bug for that and make it block bug 995519.

[1] http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp?rev=ff19c6d84718#2643
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(bugmail.mozilla)
status-b2g-v2.1: --- → affected
Component: Graphics: Layers → Panning and Zooming
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → All
See Also: → 1043859
Thanks for the explanation.

> (In reply to Kan-Ru Chen [:kanru] from comment #16)
> > I made a test case here that shows that even normal touch event has the same
> > problem:
> > 
> > http://people.mozilla.org/~kchen/1036264.html
> > 
> > Load the page in browser then try to click the green square. If the page is
> > zoomed out then the green square can't receive the "click" event.
> > 
> > So I think we have to change all the ignoreRootScrollFrame flags to true?
> 
> Was this always the case? I don't think anything has changed in this regard
> recently, but if it's not a recent regression then I'm very surprised nobody
> has noticed until now. It might be worth quickly checking a 1.3/1.4/2.0
> build to see if it happens there as well.

Checked on 1.3/1.4/2.0, they all have the syndrome. After zooming out, the green square receives only "touch"* but not "click" nor "contextmenu" event.

>                                           I know the scrollbars were only
> enabled recently (bug 995519) and the behaviour you're seeing there is
> definitely a regression. Please file a new bug for that and make it block
> bug 995519.

Filed 1043859
(In reply to Kan-Ru Chen [:kanru] from comment #22)
> Checked on 1.3/1.4/2.0, they all have the syndrome. After zooming out, the
> green square receives only "touch"* but not "click" nor "contextmenu" event.

Interesting, I guess nobody noticed until now. Crazy! But yes, we should set ignoreRootScrollFrame=true for all of those things.

> 
> Filed 1043859

Thanks!
Comment on attachment 8461383 [details] [diff] [review]
Tentative patch

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

::: dom/ipc/TabChild.cpp
@@ +1947,5 @@
>                           const int32_t&  aModifiers,
>                           const bool&     aIgnoreRootScrollFrame)
>  {
>    DispatchMouseEvent(aType, CSSPoint(aX, aY), aButton, aClickCount, aModifiers,
> +                     true, nsIDOMMouseEvent::MOZ_SOURCE_UNKNOWN);

I don't think this function gets called as part of a click. We should be able to leave this as-is. Instead, in DispatchSynthesizedMouseEvent we should set event.ignoreRootScrollFrame = true. That is the function that dispatches the mouse events that create the click, from FireSingleTapEvent.
Attachment #8461383 - Flags: feedback+

        Attachment #8461383 -
        Attachment is obsolete: true

        Attachment #8463262 -
        Flags: review?(bugmail.mozilla)

    
    

    
  


  
Tested on Flame.

        Attachment #8461385 -
        Attachment is obsolete: true

        Attachment #8463263 -
        Flags: review?(bugmail.mozilla)

    
  

        Attachment #8463262 -
        Attachment is obsolete: true

        Attachment #8463262 -
        Flags: review?(bugmail.mozilla)

    
    

    
  
Comment on attachment 8463263 [details] [diff] [review]
Always pass true for ignoreRootScrollFrame

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

LGTM, thanks!

        Attachment #8463263 -
        Flags: review?(bugmail.mozilla) → review+

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/0b8ecdc86b9c
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34

    
    

    
  

      
      
      
      

        Attached video
          
        video
        — 
      

    


  
This issue has been verified successfully on Flame 2.0 and 2.1
See attachment: Verify_1036264.MP4
Reproducing rate: 0/3

Flame 2.0 build:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141202000201
Version         32.0

Flame 2.1 build:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141202001201
Version         34.0

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: