Scrolling DIV using overflow inside IFRAME with css perspective works intermittently when dragging scrollbar. Scrolling is possible with mousewheel. (webrender only)
Categories
(Core :: Panning and Zooming, defect)
Tracking
()
People
(Reporter: tkrofecheck, Assigned: botond)
References
()
Details
Attachments
(4 files)
Webpage (Advertisement) displayed inside IFRAME, a scrollable DIV is setup using the below CSS:
position: absolute;
height: 468px;
width: 213px;
top: 1px;
right: 1px;
overflow-x: hidden;
overflow-y: hidden;
Scrolling the DIV works as expecting using mousewheel.
Scrolling the DIV does not work as expected when dragging the scrollbar. Dragging the scroll either doesn't work at all, the scrubber jumps back to the top, or the scrubber may be moved while the mouse is positioned below the scrubber.
Apologies, CSS for the scrollable DIV should be "overflow-y: scroll".
Sorry for the confusion.
Comment 2•2 years ago
|
||
I tried visiting the url from the video but the page I got looked different and I did not get the element you were interacting with.
Can you either provide a url or upload a testcase that shows the broken behaviour? Or provide some way for us to reproduce?
Hi. Sorry the URL in the video was not available, it could be related to our VPN gating the content. Please see the below google preview of this same ad, with different creative. The scrollable element is on the right side of the collapsed and the expanded ad.
https://www.google.com/doubleclick/studio/externalpreview/#/NjGHUFuZTrqOHkIEATRsuA
Thanks,
TIm
Comment 4•2 years ago
|
||
Any chance you could simplify it further? The rollover and disappear behaviour makes it annoying to investigate. Any extra boiler plate above and beyond a standalone testcase that could be easily be removed would be helpful.
Unfortunately I do not have a simple boilerplate since this is our test template with fake content.
To make it easier, if you hover over the scrolling div (right side) in the ad's collapsed state, you should be able to replicate the scroll bar not being draggable. The up/down arrows work, mousewheel works, but the scrubbing (dragging the scroller) does not work.
Comment 6•2 years ago
|
||
Is there a reason that you use CSS perspective? Removing that does not seem to change any behaviour or appearance but it fixes the scrollbar.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 7•2 years ago
|
||
Disabling apz scrollbar dragging via apz.drag.enabled=false fixes this.
Used the command
./mach mozregression -a "https://www.google.com/doubleclick/studio/externalpreview/#/NjGHUFuZTrqOHkIEATRsuA" --pref gfx.webrender.all:true gfx.webrender.enabled:true gfx.webrender.hit-test:true
to investigate this, the extra webrender prefs are needed to enabled webrender in old builds.
We go from working correctly to being a little offset in the scrollbar dragging in this range
I think this is probably just getting basic functionality working with webrender and we go from main thread scrollbar dragging to the apz scrollbar dragging.
In this range we go from being a little offset to being a large amount offset (in the down direction)
In this range we go from a large amount offset (in the down direction) to working good again
And in this range we go from working to the current broken behaviour (a larger amount of offset in the upwards direction)
Wow. That's very interesting, and extremely helpful. The code you are referring to is provided in Google's template when using their Google Web Designer to build these ads. We'll need to remove that. I appreciate your feedback and will get back to our developers and ask our product team to provide your findings to Google. Feel free to close this bug as it is not a bug with the browser.
Thank you, Tim!
~ Tim
Comment 9•2 years ago
|
||
I think scrollbars should work even with perspective so it seems like there is still a bug in the browser. If you could provide a testcase in some form that will stay there and won't go away so we can fix this bug that would be great. (I tried saving your testcase but it doesn't work after saving for some reason).
Reporter | ||
Comment 10•2 years ago
|
||
Understood. I was under the impression that you were telling me the use of perspective was incorrect, but instead that disabling it will fix it for now until the fix is made to the browser. I'll be sure to relay this information to my team. I do see you provided a link to another ticket opened 6 months ago related to this. I don't want you to have duplicate tickets on the same issue, so feel free to do what you need to with this one and I can keep an eye on the other.
Reporter | ||
Comment 11•2 years ago
|
||
On Monday when I am in our system, I can provide a ZIP containing the creative we use with Google Web Designer.
Comment 12•2 years ago
|
||
(In reply to Tim from comment #10)
Understood. I was under the impression that you were telling me the use of perspective was incorrect, but instead that disabling it will fix it for now until the fix is made to the browser.
Correct. I don't understand why you were using perspective, it seemed unnecessary (but maybe it's not), but the browser should still work correctly.
I'll be sure to relay this information to my team. I do see you provided a link to another ticket opened 6 months ago related to this. I don't want you to have duplicate tickets on the same issue, so feel free to do what you need to with this one and I can keep an eye on the other.
That other issue is related but it definitely not the same (it only affects non-webrender, this bug only affects webender, but those are terms you don't need to understand).
(In reply to Tim from comment #11)
On Monday when I am in our system, I can provide a ZIP containing the creative we use with Google Web Designer.
Thanks. I'm not familiar with that but we can use that with Google Web Designer to make a similar testcase link like you have done?
Reporter | ||
Comment 13•2 years ago
|
||
Google Web Designer will allow you to preview locally on a localhost URL, but that may not be preferred for your testing to use a third party application. I could flag the provided test URL in our account as DO-NOT-DELETE. This way you wouldn’t need Google Web Designer at all. Whatever you think will be best for you to troubleshoot, just say let me know. I’m happy to provide both too, the ZIP and flag the URL.
Reporter | ||
Comment 14•2 years ago
|
||
Setup Instruction for Google Web Designer Template (Windows & MacOS)
Reporter | ||
Comment 15•2 years ago
|
||
Google Web Designer Template (ZIP) - must be uncompressed in the location mention in setup instructions for Windows / MacOS.
Reporter | ||
Comment 16•2 years ago
|
||
Please find attached a PDF with setup instructions along with a ZIP containing the template used with Google Web Designer, should you want to debug via the "Preview" in a localhost environment. I have flagged the provided test URL on this ticket as well to not be deleted. Please let me know if you need anything further.
Comment 17•2 years ago
|
||
I've run into what I believe is the same issue (a scrollable div inside an iframe that cannot be scrolled by dragging the scrollbar's handle). I've attached a minimal example to reproduce this problem. I do not use CSS perspective, but I did use a transform: translateX() to position the iframe, that seems to be key to the issue because the iframe can be positioned in other ways such as with left padding without the scrollbar issue. While there are workarounds the scrollbars should work even with the translateX().
Comment 18•2 years ago
|
||
Moving APZ as per comment 12. I also confirmed the test case in comment 17 seems to be same. Probably we need to factor the transform matrix somewhere in APZ hit testing code.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 19•1 year ago
|
||
I'm not able to reproduce the issue in the test case from comment 17 any more.
Assignee | ||
Comment 20•1 year ago
|
||
(In reply to Botond Ballo [:botond] from comment #19)
I'm not able to reproduce the issue in the test case from comment 17 any more.
Fix range points to a recent change made in the Firefox 100 cycle, bug 1753779.
Assignee | ||
Comment 21•1 year ago
|
||
Tim, would you be able to check in the latest Firefox Nightly if your original issue is resolved as well?
(I did follow the instructions in comment 15 to generate and load the page showing your problem, but on that page I could not reproduce the bug in older Firefox versions either.)
Assignee | ||
Comment 22•1 year ago
|
||
I'm going to assume this was fixed by bug 1753779 and close it.
Tim, if it turns out the original issue is not fixed for you in the latest Firefox Nightly, please feel free to reopen and share an updated test case.
Description
•