Bug 157771

Summary: AX: iOS: when bringing focus to a text field we may zoom the page even if author wanted max scale = 1
Product: WebKit Reporter: chris fleizach <cfleizach>
Component: AccessibilityAssignee: chris fleizach <cfleizach>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, enrica, jonlee, simon.fraser, thorton, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Other   
Hardware: All   
OS: All   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
simon.fraser: review-
Patch
none
Patch
none
Patch
none
Patch thorton: review+

Description chris fleizach 2016-05-16 16:48:34 PDT
If a user taps on a text field to bring keyboard focus, we should not zoom the page in if the author had set scaling to NO

We should only do scaling if the user does it themselves



<rdar://problem/25443355>
Comment 1 chris fleizach 2016-05-16 16:52:48 PDT
Created attachment 279068 [details]
Patch
Comment 2 chris fleizach 2016-05-16 16:56:08 PDT
Created attachment 279070 [details]
Patch
Comment 3 WebKit Commit Bot 2016-05-16 16:57:56 PDT
Attachment 279070 [details] did not pass style-queue:


ERROR: Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1053:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
ERROR: Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1054:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 2 in 11 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 4 chris fleizach 2016-05-16 17:09:13 PDT
Comment on attachment 279070 [details]
Patch

ToT changed on me
Comment 5 chris fleizach 2016-05-17 16:32:15 PDT
Created attachment 279180 [details]
Patch
Comment 6 WebKit Commit Bot 2016-05-17 16:33:26 PDT
Attachment 279180 [details] did not pass style-queue:


ERROR: Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1053:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
ERROR: Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1054:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 2 in 10 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 7 Simon Fraser (smfr) 2016-05-17 16:44:39 PDT
Comment on attachment 279180 [details]
Patch

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

> Source/WebKit2/WebProcess/WebPage/WebPage.h:512
> +    // maximumPageScaleFactor accounts for when user scaling is enabled by force.
>      double maximumPageScaleFactor() const;
> +    
> +    // originalMaximumScaleFactor is the default page scaling of the page.
> +    double originalMaximumScaleFactor() const;

I don't think these names are clear. In particular, "by force" is unclear.

Maybe:
maximumAllowablePageScaleFactor()
maximumPageScaleFactorFromViewportTag()
Comment 8 chris fleizach 2016-05-17 16:54:50 PDT
Created attachment 279186 [details]
Patch
Comment 9 WebKit Commit Bot 2016-05-17 16:56:41 PDT
Attachment 279186 [details] did not pass style-queue:


ERROR: Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1053:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
ERROR: Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1054:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 2 in 12 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 10 Simon Fraser (smfr) 2016-05-17 17:14:08 PDT
Comment on attachment 279186 [details]
Patch

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

> Source/WebCore/page/ViewportConfiguration.h:89
> +    bool forceAlwaysUserScalable() { return m_forceAlwaysUserScalable; }

This should be const

> Source/WebKit2/Shared/AssistedNodeInformation.h:103
> +    bool userScalingForced { false };

This is also ambiguous. Does it mean that the user has zoomed when forceAlwaysUserScalable() is true, or does it just reflect forceAlwaysUserScalable()? I can't tell from this patch.
Comment 11 chris fleizach 2016-05-18 11:44:16 PDT
Created attachment 279265 [details]
Patch
Comment 12 WebKit Commit Bot 2016-05-18 11:46:04 PDT
Attachment 279265 [details] did not pass style-queue:


ERROR: Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1053:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
ERROR: Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1054:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 2 in 13 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 13 Simon Fraser (smfr) 2016-05-18 11:58:35 PDT
Comment on attachment 279265 [details]
Patch

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

> Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1054
> +              allowScaling:(_assistedNodeInformation.allowsUserScaling && !_assistedNodeInformation.forceAlwaysUserScalable && !UICurrentUserInterfaceIdiomIsPad())

Doesn't this mean that a user with "always allow scaling" set is going to never get zooming on an input on iPhone?
Comment 14 chris fleizach 2016-05-18 12:33:29 PDT
(In reply to comment #13)
> Comment on attachment 279265 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=279265&action=review
> 
> > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1054
> > +              allowScaling:(_assistedNodeInformation.allowsUserScaling && !_assistedNodeInformation.forceAlwaysUserScalable && !UICurrentUserInterfaceIdiomIsPad())
> 
> Doesn't this mean that a user with "always allow scaling" set is going to
> never get zooming on an input on iPhone?

Possibly... Looking
Comment 15 chris fleizach 2016-05-18 12:38:35 PDT
(In reply to comment #14)
> (In reply to comment #13)
> > Comment on attachment 279265 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=279265&action=review
> > 
> > > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1054
> > > +              allowScaling:(_assistedNodeInformation.allowsUserScaling && !_assistedNodeInformation.forceAlwaysUserScalable && !UICurrentUserInterfaceIdiomIsPad())
> > 
> > Doesn't this mean that a user with "always allow scaling" set is going to
> > never get zooming on an input on iPhone?
> 
> Possibly... Looking

Probably don't need _assistedNodeInformation.forceAlwaysUserScalable  at all, since maximumPageScaleFactorFromViewportTag will be 1x in this case

Rebuilding and testing...
Comment 16 Simon Fraser (smfr) 2016-05-18 12:53:51 PDT
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > Comment on attachment 279265 [details]
> > > Patch
> > > 
> > > View in context:
> > > https://bugs.webkit.org/attachment.cgi?id=279265&action=review
> > > 
> > > > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1054
> > > > +              allowScaling:(_assistedNodeInformation.allowsUserScaling && !_assistedNodeInformation.forceAlwaysUserScalable && !UICurrentUserInterfaceIdiomIsPad())
> > > 
> > > Doesn't this mean that a user with "always allow scaling" set is going to
> > > never get zooming on an input on iPhone?
> > 
> > Possibly... Looking
> 
> Probably don't need _assistedNodeInformation.forceAlwaysUserScalable  at
> all, since maximumPageScaleFactorFromViewportTag will be 1x in this case
> 
> Rebuilding and testing...

Please add a layout test for that case too.
Comment 17 chris fleizach 2016-05-19 10:11:26 PDT
Created attachment 279397 [details]
Patch

Added a unit test for the case where we don't want to zoom in and the case where we DO want to zoom in
Comment 18 WebKit Commit Bot 2016-05-19 10:13:38 PDT
Attachment 279397 [details] did not pass style-queue:


ERROR: Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1054:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 1 in 16 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 19 chris fleizach 2016-05-19 23:08:40 PDT
@simon: how does this look?
Comment 20 Tim Horton 2016-05-21 19:03:45 PDT
Comment on attachment 279397 [details]
Patch

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

> Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1047
> +    // In case user scaling is force enabled, do not use that scaling when zomming in with an input field.

sp: zomming

> Source/WebKit2/WebProcess/WebPage/WebPage.h:509
> +    // maximumAllowablePageScaleFactor is the max page scaling that also accounts for whether the preference for "always scale" is enabled.

s/scaling/scale/

> Source/WebKit2/WebProcess/WebPage/WebPage.h:511
> +    // maximumPageScaleFactorFromViewportTag is the default page scaling of the page. It does not account for when the preference for "always scale" is enabled.

ditto.

> Source/WebKit2/WebProcess/WebPage/ios/WebPageIOS.mm:340
> +    return m_page->pageScaleFactor();

How is the current live page scale a "maximum" of any sort?
Comment 21 chris fleizach 2016-05-22 13:51:47 PDT
Created attachment 279552 [details]
Patch
Comment 22 WebKit Commit Bot 2016-05-22 13:52:36 PDT
Attachment 279552 [details] did not pass style-queue:


ERROR: Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1055:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 1 in 11 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 23 chris fleizach 2016-05-22 13:52:44 PDT
(In reply to comment #20)
> Comment on attachment 279397 [details]
> Patch
> 

Thanks for review. Addressed comments and also removed unnecessary changes. The patch had morphed a bit from the beginning and we don't need nearly as many changes as originally thought

thanks

> View in context:
> https://bugs.webkit.org/attachment.cgi?id=279397&action=review
> 
> > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1047
> > +    // In case user scaling is force enabled, do not use that scaling when zomming in with an input field.
> 
> sp: zomming
> 
> > Source/WebKit2/WebProcess/WebPage/WebPage.h:509
> > +    // maximumAllowablePageScaleFactor is the max page scaling that also accounts for whether the preference for "always scale" is enabled.
> 
> s/scaling/scale/
> 
> > Source/WebKit2/WebProcess/WebPage/WebPage.h:511
> > +    // maximumPageScaleFactorFromViewportTag is the default page scaling of the page. It does not account for when the preference for "always scale" is enabled.
> 
> ditto.
> 
> > Source/WebKit2/WebProcess/WebPage/ios/WebPageIOS.mm:340
> > +    return m_page->pageScaleFactor();
> 
> How is the current live page scale a "maximum" of any sort?
Comment 24 Tim Horton 2016-05-23 10:20:51 PDT
Comment on attachment 279552 [details]
Patch

This seems much less crazy.
Comment 25 chris fleizach 2016-05-23 13:43:15 PDT
http://trac.webkit.org/changeset/201294