Bug 198623 - Images are not resizing correctly when dragged to a message in 1/3 view
Summary: Images are not resizing correctly when dragged to a message in 1/3 view
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: zalan
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-06-06 14:36 PDT by zalan
Modified: 2019-06-07 10:50 PDT (History)
6 users (show)

See Also:


Attachments
Patch (24.73 KB, patch)
2019-06-06 15:09 PDT, zalan
no flags Details | Formatted Diff | Diff
Patch (18.86 KB, patch)
2019-06-07 09:44 PDT, zalan
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description zalan 2019-06-06 14:36:47 PDT
<rdar://problem/51185518>
Comment 1 zalan 2019-06-06 15:09:24 PDT
Created attachment 371527 [details]
Patch
Comment 2 Darin Adler 2019-06-06 15:47:42 PDT
Comment on attachment 371527 [details]
Patch

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

> Source/WebCore/editing/WebContentReader.h:74
> +    bool readFilePath(const String&, Optional<float> preferredPresentationWidth = { }, Optional<float> preferredPresentationHeight = { }, const String& contentType = { }) override;

Not critical, but a tiny bit inelegant to have such a long list of arguments. Maybe would be nice just to have a struct just for the width/height (both optional) so it’s easier to pass along from one function to the next and also easier to ignore. This might just clean it up a bit:

struct OptionalSizes {
    Optional<float> width;
    Optional<float> height;
};

Not sure that’s the perfect name, but it’s important that it’s a short name.

On a separate note, not at all new to this patch, it’s not so ideal to turn CGFloat (double) into float and then turn it into a string. Could end up with a long string that would be shorter if it wasn’t converted to a float first. Generally speaking I think that the mix of floating point types is a small problem throughout our graphics code.

> Source/WebCore/platform/ios/PlatformPasteboardIOS.mm:161
> +        if (!IOSApplication::isMobileMail())

This needs a "why" comment. It’s very mysterious to have an unmotivated "if specific app" here. Even better would be to have a function name that makes it clear what the quirk in behavior is, not just a comment.
Comment 3 zalan 2019-06-06 15:53:07 PDT
(In reply to Darin Adler from comment #2)
> Comment on attachment 371527 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=371527&action=review
> 
> > Source/WebCore/editing/WebContentReader.h:74
> > +    bool readFilePath(const String&, Optional<float> preferredPresentationWidth = { }, Optional<float> preferredPresentationHeight = { }, const String& contentType = { }) override;
> 
> Not critical, but a tiny bit inelegant to have such a long list of
> arguments. Maybe would be nice just to have a struct just for the
> width/height (both optional) so it’s easier to pass along from one function
> to the next and also easier to ignore. This might just clean it up a bit:
> 
> struct OptionalSizes {
>     Optional<float> width;
>     Optional<float> height;
> };
> 
I use such structures all the time in the layout code! I should have done that here too.

> Not sure that’s the perfect name, but it’s important that it’s a short name.
> 
> On a separate note, not at all new to this patch, it’s not so ideal to turn
> CGFloat (double) into float and then turn it into a string. Could end up
> with a long string that would be shorter if it wasn’t converted to a float
> first. Generally speaking I think that the mix of floating point types is a
> small problem throughout our graphics code.
> 
> > Source/WebCore/platform/ios/PlatformPasteboardIOS.mm:161
> > +        if (!IOSApplication::isMobileMail())
> 
> This needs a "why" comment. It’s very mysterious to have an unmotivated "if
> specific app" here. Even better would be to have a function name that makes
> it clear what the quirk in behavior is, not just a comment.
Agree. Will add one.
Comment 4 zalan 2019-06-07 09:44:56 PDT
Created attachment 371589 [details]
Patch
Comment 5 WebKit Commit Bot 2019-06-07 10:50:08 PDT
The commit-queue encountered the following flaky tests while processing attachment 371589 [details]:

resize-observer/element-leak.html bug 198667
The commit-queue is continuing to process your patch.
Comment 6 WebKit Commit Bot 2019-06-07 10:50:55 PDT
Comment on attachment 371589 [details]
Patch

Clearing flags on attachment: 371589

Committed r246207: <https://trac.webkit.org/changeset/246207>
Comment 7 WebKit Commit Bot 2019-06-07 10:50:57 PDT
All reviewed patches have been landed.  Closing bug.