[Webkit-unassigned] [Bug 153404] REGRESSION(r188659): Non main frame scrollable areas don't work for pages restored from the page cache

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Feb 16 03:43:24 PST 2016


https://bugs.webkit.org/show_bug.cgi?id=153404

--- Comment #10 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #9)
> (In reply to comment #8)
> > Comment on attachment 271347 [details]
> > Different WIP approach
> > 
> > Seems reasonable, but you should make sure that you can actually get back to
> > the FrameView in these two destructors (might be too late).
> 
> Disconnecting destroyed renderers from the FrameView seems like a good thing
> to be doing. So if this changes fixes your problem, without reintroducing
> the issues from Bug 148182, then I'm in favor of it.

I can't be sure it doesn't reintroduce the issues from bug #148182, because I haven't been able to reproduce those crashes. Based on the analysis made in that bug I assume the problem is only with PDFPlugin, and it should be fixed by unregistering the plugin in the destructor, but someone with a mac who can reproduce the issue should confirm it.

> However, I don't really like that various Render elements have to do work to
> keep things in proper balance. E.g., RenderListBox and RenderLayer have
> cleanup code, now DeprecatedPDFPlugin will have special code.

I think it makes sense that classes registering themselves as scrollable areas unregister themselves as well. Ideally the base class could do it, but ScrollableArea is in platform layer and FrameView in WebCore layer. So, I don't think DeprecatedPDFPlugin will have any special code, it's registering itself as scrollable area in the FrameView and should unregister if it's destructed.

> Are there
> others we are missing?

No, there aren't.

> Should ScrollableAreas know about their containing frames, so they can
> unregister themselves during destruction, rather than doing so in the
> individual destructors for ScrollableArea descendants?

That would be a layering violation.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160216/91406cb3/attachment-0001.html>


More information about the webkit-unassigned mailing list