• petruta
    Hello! Does anyone know if there's a bug on file for this Facebook scrolling issue: drive.google.com/file/d/0B7jBNZBM3mz-SHZMNEdOaHJaNHM/view?usp=sharing ?
  • petruta
    Basically after login, on some pages that have several links on the right side, scrolling the timelime will move that div up/down while it should be fixed on page. This happens on older Fx versions too, but I couldn't find the regression so I'm assuming it might be a recent modification on their side.
  • kats
    petruta: no bug on file that i'm aware of for that
  • petruta
    Thanks kats, I'm filling one now.
  • kats
    thanks
  • petruta
  • firebot
    Bug 1399495 — NEW, nobody⊙mozilla.org — Jerkiness while scrolling on Facebook pages
  • rhunt
    botond: ping
  • botond|home
    rhunt: pong
  • rhunt
    botond: so I think you've addressed all the things I saw in your scrollbar dragging patches, and I also did a little bit of testing on your laptop and couldn't find anything obvious so I think you should be good to land
  • botond|home
    rhunt: great, thanks! i'm just doing some final testing locally, and will land soon
  • botond|home
    rhunt: thanks for the reviews :)
  • rhunt
    botond: awesome, your patches were well written so once I knew the existing code it was easy :)
  • rhunt
    kats: ping
  • kats
    rhunt: pong
  • rhunt
    kats: I was using botond's touch laptop and noticed a weird behavior with zooming and tracked it down to bug 789906
  • firebot
    bugzil.la/789906 — NEW, nobody⊙mozilla.org — When using touch UI (for example on Win8), zooming shouldn't reflow, but just scale
  • rhunt
    kats: I saw you mentioned it'd be a bit of work to fix, do you have a summary of what's involved?
  • kats
    rhunt: it's been a while since i looked, but i think the main problem was that trying to do pinch-zooming with containerless scrollframes doesn't work very well
  • kats
    rhunt: we have containerless scrollframes on desktop but not on android
  • kats
    so on android it works
  • rhunt
    kats: a containerless scrollframe?
  • kats
    and there was some reason we couldn't use containerful scrollframes on desktop, but i can't remember what it was
  • kats
  • kats
    with containerfull scrolling we have a container layer wrapping all the things that scroll, and the scroll metadata goes on that layer
  • kats
    with containerless there is no container layer, and the metadata is put on each child layer instead
  • kats
    (that's a simplified version, i don't even remember all the details)
  • rhunt
    kats: interesting
  • kats
    rhunt: did you try running with apz.allow_zooming set to true?
  • rhunt
    kats: no, I didn't. I'll give it a shot
  • kats
    rhunt: what was the zooming problem you saw?
  • rhunt
    kats: not a problem, but just that it does full zoom when I think most people expect touch to work like on their phone
  • kats
    yeah
  • kats
    getting pinch zoom working on desktop has been on our to-do list for a while but it keeps getting pushed back
  • rhunt
    kats: so for some reason i'm not able to trigger pinch zooming with apz.allow_zoom enabled
  • kats
    rhunt: hm, maybe it's broken more since the last time i tried
  • rhunt
    kats: what was broken before, if you remember?
  • kats
    rhunt: i don't recall offhand. it's probably been a year at least since i tried it
  • rhunt
    kats: np, just curious
  • botond|home
    rhunt: you're getting a pinch gesture causing full-zoom on the touchscreen laptop?
  • botond|home
    rhunt: what page?
  • kats
    that's the expected behaviour currently
  • rhunt
    botond: yeah, but it has nothing to do with your patches I was just testing out touch input
  • botond|home
    kats: do you know how it's implemented?
  • kats
  • botond|home
    kats: ah, right, NotifyPunchGesture. i should remember that since i reviewed it :p
  • kats
    Punch gesture! we should totally add that
  • kats
    punch the screen to file a bug
  • botond|home
    lol!
  • botond|home
    whoops
  • rhunt
    heh
  • botond|home
    kats: do you know if the handling of that on the content side is platform-specific?
  • kats
  • kats
    although i'm not totally sure
  • botond|home
    kats: i'm not getting full-zoom on my Linux touch laptop... was just wondering if that's expected. after all, getting full-zoom is better than nothing
  • kats
    botond: that might be worth looking into
  • kats
    i thought it was supposed to work
  • botond|home
  • botond|home
    kats: so looks like it's Windows-only for now
  • kats
    botond: ah. presumably you can modify the pref locally and see what happens
  • botond|home
    kats: seems to work after setting the pref locally
  • botond|home
    kats: i think we can probably just enable this on Linux. the comment for why it's disabled refers to "issues with track pad input
  • botond|home
    ", but i don't believe track pads generate pinch gesture on Linux
  • botond|home
    (also it dates back to 2011, which is long before we had any touch support on Linux)
  • kats
    botond: sounds ok to me
  • kats
    we can always re-disable it if there's issues
  • botond|home
    mstange: ping?
  • botond|home
    rhunt: i think i know why you're not seeing pinch-zoom behaviour with apz.allow_zooming set to true
  • botond|home
    rhunt: you need to also set dom.meta-viewport.enabled to true, because of this: searchfox.org/mozilla-central/source/dom/base/nsDocument.cpp#8078
  • botond|home
    rhunt: with both of those prefs set, i can perform pinch-zooming
  • botond|home
    rhunt: the most prominent issue that i notice is that scrollbars aren't drawn after you zoom in
  • mstange
    botond|home: pong
  • botond|home
    mstange: hey! i was going to ask you the question i wrote up in bugzilla.mozilla.org/1382534#c39. if you happen to have any insight about it, feel free to share, otherwise i'll wait for CJ to weigh in
  • firebot
    Bug 1382534 — NEW, botond⊙mozilla.com — Black gaps when scrolling BBC photo gallery
  • mstange
    botond|home: I see, I don't have any insight about it
  • botond|home
    mstange: ok, no worries
  • mstange
    but the answer is probably "there's currently no faster version to get bounds for the actual path, but maybe you can add one"
  • botond|home
    mstange: is speed the only reason i may not want to create a DrawTarget at display list building time?
  • mstange
    botond|home: I can't think of another reason
  • botond|home
    mstange: ok. i thought perhaps we may not have the necessary information to choose the kind of DT to create, or other such prerequisites, at display list building time
  • mstange
    hmm
  • botond|home
    mstange: but if that's not the case, i can try creating a DT, at least for now as a temporary solution
  • mstange
    we have places where we use the ScreenReferenceDT to obtain path bounds, I think
  • mstange
    ScreenReferenceDrawTarget
  • botond|home
    mstange: ooh, that sounds useful!
  • mstange
    SVGGeometryFrame::GetBBoxContribution does something like this
  • botond|home
    mstange: indeed! and i call that function (indirectly) for the clip-path:url() case
  • mstange
    heh
  • botond|home
    mstange: so, i suppose there's no reason i couldn't go with the same approach for basic-shape
  • mstange
    I agree
  • botond|home
    mstange: thanks for pointing me to that!
  • mstange
    you're welcome :)
  • botond|home
    mstange: (you're more insightful that you give yourself creditor for :p)
  • botond|home
    than*
  • botond|home
    credit* (can't spell today...)
  • mstange
    heh