Closed Bug 1696661 Opened 3 years ago Closed 2 years ago

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)

Firefox 86
Desktop
All
defect

Tracking

()

RESOLVED DUPLICATE of bug 1753779

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.

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?

Flags: needinfo?(tkrofecheck)

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

Flags: needinfo?(tkrofecheck)

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.

Flags: needinfo?(tkrofecheck)

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.

Flags: needinfo?(tkrofecheck)

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.

Flags: needinfo?(tkrofecheck)
Summary: Scrolling DIV using overflow inside IFRAME works intermittently when dragging scrollbar. Scrolling is possible with mousewheel. → Scrolling DIV using overflow inside IFRAME with css perspective works intermittently when dragging scrollbar. Scrolling is possible with mousewheel. (webrender only)
See Also: → 1662287

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

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=de32269720d056972b85f4eec5f0a8286de6e3af&tochange=56d6db4ad38c869d0bbc2aea449a4a382f109163

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)

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a456475502b80a1264642d9eaee9394a8fad8315&tochange=dcd10220d55aea46db212314c46d25a96a7be243

In this range we go from a large amount offset (in the down direction) to working good again

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=182a1b088330a2d72310ae2561004d955571e236&tochange=e05552012e193e1effac4c01dd149c6e6b51f30b

And in this range we go from working to the current broken behaviour (a larger amount of offset in the upwards direction)

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f2915d3ee5f8705676e4bb643eab54b62246f25f&tochange=6453222232be364fb8ce3fd29b6cbcd480e5f2e3

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

Flags: needinfo?(tkrofecheck)

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).

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.

On Monday when I am in our system, I can provide a ZIP containing the creative we use with Google Web Designer.

(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?

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.

Setup Instruction for Google Web Designer Template (Windows & MacOS)

Google Web Designer Template (ZIP) - must be uncompressed in the location mention in setup instructions for Windows / MacOS.

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.

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().

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.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Component: Layout: Scrolling and Overflow → Panning and Zooming
Ever confirmed: true
Assignee: nobody → botond
Blocks: 1745834
No longer blocks: 1745834

I'm not able to reproduce the issue in the test case from comment 17 any more.

(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.

Depends on: 1753779

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.)

Flags: needinfo?(tkrofecheck)

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.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(tkrofecheck)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: