[webkit-reviews] review granted: [Bug 237451] Home link on weather.gov is not working : [Attachment 453809] Patch

[bugzilla-daemon at webkit.org]

Geoffrey Garen <ggaren at apple.com> has granted Chris Dumez <cdumez at apple.com>'s
request for review:
Bug 237451: Home link on weather.gov is not working
https://bugs.webkit.org/show_bug.cgi?id=237451

Attachment 453809: Patch

https://bugs.webkit.org/attachment.cgi?id=453809&action=review




--- Comment #8 from Geoffrey Garen <ggaren at apple.com> ---
Comment on attachment 453809
  --> https://bugs.webkit.org/attachment.cgi?id=453809
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=453809&action=review

Looks good!

Comment below about WeakPtr. I guess I am parroting years of Darin explaining
to me that basing behaviors on destructors is not a good pattern.

> Source/WebCore/ChangeLog:14
> +	   We only only resolve the target history entry once the scheduled
task runs asynchronously.

only only

> Source/WebCore/loader/NavigationScheduler.cpp:276
> +	   if (!m_historyItem)
> +	       return;

I suppose that we could just make the HistoryItem a RefPtr and guarantee that
the navigation succeeds.

Is the goal here that the navigation should fail if the history item has been
removed from the back-forward list? (Is that required by spec or WPT?)

If that's the goal, I wonder if we should use a RefPtr and an explicit
"isInList" boolean, or an explicit scan of the list, rather than a weak
pointer. In theory, object lifetime is allowed to do whatever it wants, and a
lambda or GC or tree of objects or whatever might change lifetime in unexpected
ways, causing a navigation to succeed or fail in surprising ways.

> LayoutTests/TestExpectations:346
> +# This test is timing out in both WebKit in Blink (one of the subtests is
timing out in Gecko).

WebKit and Blink