Summary: | Clicking where the overlay scroll track would be should not scroll the page | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Mark Mentovai <mark> | ||||||||
Component: | New Bugs | Assignee: | Beth Dakin <bdakin> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | ap, bdakin, sail, sam, tkent, webkit-bug-importer, webkit.review.bot | ||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Attachments: |
|
Description
Mark Mentovai
2011-10-31 12:09:16 PDT
(In reply to comment #1) > <rdar://problem/10373860> That bug has been marked a duplicate of this one: <rdar://problem/9585424> Created attachment 122329 [details]
Patch
Comment on attachment 122329 [details]
Patch
Do we need the same check in BuiltinPDFView?
(In reply to comment #4) > (From update of attachment 122329 [details]) > Do we need the same check in BuiltinPDFView? Oh, thank you for the reminder! We probably do. I will look into that now. (In reply to comment #5) > (In reply to comment #4) > > (From update of attachment 122329 [details] [details]) > > Do we need the same check in BuiltinPDFView? > > Oh, thank you for the reminder! We probably do. I will look into that now. Looks like PDFs don't have this bug, actually. (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (From update of attachment 122329 [details] [details] [details]) > > > Do we need the same check in BuiltinPDFView? > > > > Oh, thank you for the reminder! We probably do. I will look into that now. > > Looks like PDFs don't have this bug, actually. Oh, I take it back! Alexey sent me a test case that does show the bug. Comment on attachment 122329 [details]
Patch
I will post a new patch shortly that fixes PDF too. If anyone can suggest a different name for Scrollbar::isCurrentlyVisible(), I'd love to hear it. Scrollbar's parent class Widget already has a function called isVisible() that has a different meaning, so it seems wrong to re-use that.
Created attachment 122479 [details]
Patch that fixes PDF as well
Comment on attachment 122479 [details] Patch that fixes PDF as well View in context: https://bugs.webkit.org/attachment.cgi?id=122479&action=review > Source/WebCore/platform/Scrollbar.cpp:421 > + if (!isClickable()) > + return false; If I'm reading it correctly, clicks in invisible scroll bars will not be handled by underlying PDF content. That's not a problem now, given that we don't support any links or forms in BuiltinPDFView, but we need to make sure that those work correctly eventually. That would mean that hit testing should return PluginView, not the Scrollbar. Created attachment 122494 [details]
Better patch that also fixed PDF
You're right, Alexey. I think I got it this time!
Comment on attachment 122494 [details]
Better patch that also fixed PDF
The "clickable" concept could be somewhat confusing - is a visible, but disabled scrollbar clickable? Looks like the code uses both meanings in different places.
Then again, I'm not sure what it means for a scrollbar to be disabled.
Thanks for the review! (In reply to comment #12) > (From update of attachment 122494 [details]) > The "clickable" concept could be somewhat confusing - is a visible, but disabled scrollbar clickable? Looks like the code uses both meanings in different places. > > Then again, I'm not sure what it means for a scrollbar to be disabled. Hmm, this is a good point. I suppose isHitTestable would be more accurate, but that is not great either because it sounds a bit clumsy. I will think about it a bit more before I check in. Committed with http://trac.webkit.org/changeset/105006 And I changed the name of isClickable() to shouldParticipateInHitTesting() as Alexey suggested on irc. |