Bug 197523 - NSAttributedString conversion in a loop returns nil and WKUnknownError every other time
Summary: NSAttributedString conversion in a loop returns nil and WKUnknownError every ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Timothy Hatcher
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-05-02 11:30 PDT by Timothy Hatcher
Modified: 2019-05-02 16:22 PDT (History)
6 users (show)

See Also:


Attachments
Patch (4.63 KB, patch)
2019-05-02 13:12 PDT, Timothy Hatcher
no flags Details | Formatted Diff | Diff
Patch (5.06 KB, patch)
2019-05-02 15:43 PDT, Timothy Hatcher
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Timothy Hatcher 2019-05-02 11:30:48 PDT
This only happens on iOSMac for some reason.

<rdar://problem/50285662>
Comment 1 Timothy Hatcher 2019-05-02 13:12:15 PDT
Created attachment 368812 [details]
Patch
Comment 2 Darin Adler 2019-05-02 14:50:31 PDT
Comment on attachment 368812 [details]
Patch

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

> Source/WebKit/ChangeLog:12
> +        would be confused with the real content loading. Ultimatly this wasn't needed
> +        since a process swap will likely happen, and cached views are closed quickly.
> +        It also avoids extra work and speeds up conversions a bit.

Typo: Ultimatly

The word "likely" here does not inspire confidence in me that this code is correct. How can something that will "likely" happen make something not needed. It seems that it will make it "likely not needed", which is not good enough for correctness.

There must be some other reason it’s not needed.

> Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm:211
> +    result.string = attributedStringFromRange(rangeOfContents(*m_page->mainFrame().document()->documentElement()), &documentAttributes);

I think the old code would fail cleanly if documentElement() was null, so maybe we want to preserve that property. Or is there a guarantee that documentElement() is non-null?
Comment 3 Timothy Hatcher 2019-05-02 15:43:54 PDT
Created attachment 368830 [details]
Patch
Comment 4 Timothy Hatcher 2019-05-02 15:47:43 PDT
Comment on attachment 368812 [details]
Patch

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

>> Source/WebKit/ChangeLog:12
>> +        It also avoids extra work and speeds up conversions a bit.
> 
> Typo: Ultimatly
> 
> The word "likely" here does not inspire confidence in me that this code is correct. How can something that will "likely" happen make something not needed. It seems that it will make it "likely not needed", which is not good enough for correctness.
> 
> There must be some other reason it’s not needed.

A process swap might not happen if a same origin conversion happens. But that isn't what fixed this issue, a process swap just makes the extra work I was trying to do to clean things up with an about:blank load pointless.

I reworded this in the new patch.

>> Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm:211
>> +    result.string = attributedStringFromRange(rangeOfContents(*m_page->mainFrame().document()->documentElement()), &documentAttributes);
> 
> I think the old code would fail cleanly if documentElement() was null, so maybe we want to preserve that property. Or is there a guarantee that documentElement() is non-null?

Good point. I didn't hit a null case, but it could be. I added a null check on documentElement. I'm still using rangeOfContents() for its simplicity.
Comment 5 WebKit Commit Bot 2019-05-02 16:22:45 PDT
Comment on attachment 368830 [details]
Patch

Clearing flags on attachment: 368830

Committed r244893: <https://trac.webkit.org/changeset/244893>
Comment 6 WebKit Commit Bot 2019-05-02 16:22:47 PDT
All reviewed patches have been landed.  Closing bug.