WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
210344
http/tests/in-app-browser-privacy/app-bound-domain.html is a constant failure on iOS
https://bugs.webkit.org/show_bug.cgi?id=210344
Summary
http/tests/in-app-browser-privacy/app-bound-domain.html is a constant failure...
Kate Cheney
Reported
2020-04-10 10:25:28 PDT
The in-app-browser-privacy tests try to enable in-app browser privacy as an internal debug flag, but it is not an internal debug feature.
Attachments
Patch
(6.76 KB, patch)
2020-04-10 10:40 PDT
,
Kate Cheney
no flags
Details
Formatted Diff
Diff
Patch
(7.41 KB, patch)
2020-04-13 11:50 PDT
,
Kate Cheney
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Kate Cheney
Comment 1
2020-04-10 10:26:10 PDT
<
rdar://problem/61583925
>
Kate Cheney
Comment 2
2020-04-10 10:40:44 PDT
Created
attachment 396101
[details]
Patch
Alex Christensen
Comment 3
2020-04-13 10:26:01 PDT
Comment on
attachment 396101
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=396101&action=review
> Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm:127 > +#if PLATFORM(IOS_FAMILY)
Why is this not needed on Mac?
Kate Cheney
Comment 4
2020-04-13 10:28:31 PDT
(In reply to Alex Christensen from
comment #3
)
> Comment on
attachment 396101
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=396101&action=review
> > > Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm:127 > > +#if PLATFORM(IOS_FAMILY) > > Why is this not needed on Mac?
This is an iOS feature only, so this option should only be set if the tests are running iOS (they are skipped on other platforms).
Alex Christensen
Comment 5
2020-04-13 10:37:09 PDT
Comment on
attachment 396101
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=396101&action=review
> Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm:131 > + [[NSUserDefaults standardUserDefaults] setBool:NO forKey:@"WebKitDebugIsInAppBrowserPrivacyEnabled"];
Two thoughts: 1. TestController::platformAddTestOptions is a place where we are supposed to be writing to options, and this reads from options. I think TestController::platformResetPreferencesToConsistentValues or TestController::platformResetStateToConsistentValues and maybe TestController::updatePlatformSpecificTestOptionsForTest would be a better place to reset and set these values in NSUserDefaults. 2. Instead of setting the bool to NO, let's remove object for key.
Kate Cheney
Comment 6
2020-04-13 11:37:25 PDT
(In reply to Alex Christensen from
comment #5
)
> Comment on
attachment 396101
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=396101&action=review
> > > Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm:131 > > + [[NSUserDefaults standardUserDefaults] setBool:NO forKey:@"WebKitDebugIsInAppBrowserPrivacyEnabled"]; > > Two thoughts: > 1. TestController::platformAddTestOptions is a place where we are supposed > to be writing to options, and this reads from options. I think > TestController::platformResetPreferencesToConsistentValues or > TestController::platformResetStateToConsistentValues and maybe > TestController::updatePlatformSpecificTestOptionsForTest would be a better > place to reset and set these values in NSUserDefaults. > 2. Instead of setting the bool to NO, let's remove object for key.
I don't think this will work because updatePlatformSpecificTestOptionsForTest() is called before updateTestOptionsFromTestHeader() in TestController::testOptionsForTest(), so it doesn't have the updated value. Then I think platformResetStateToConsistentValues is called at the end of the test, so I can remove the key there but not set it prior to the test.
Kate Cheney
Comment 7
2020-04-13 11:50:56 PDT
Created
attachment 396313
[details]
Patch
Kate Cheney
Comment 8
2020-04-13 11:51:55 PDT
(In reply to katherine_cheney from
comment #6
)
> (In reply to Alex Christensen from
comment #5
) > > Comment on
attachment 396101
[details]
> > Patch > > > > View in context: > >
https://bugs.webkit.org/attachment.cgi?id=396101&action=review
> > > > > Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm:131 > > > + [[NSUserDefaults standardUserDefaults] setBool:NO forKey:@"WebKitDebugIsInAppBrowserPrivacyEnabled"]; > > > > Two thoughts: > > 1. TestController::platformAddTestOptions is a place where we are supposed > > to be writing to options, and this reads from options. I think > > TestController::platformResetPreferencesToConsistentValues or > > TestController::platformResetStateToConsistentValues and maybe > > TestController::updatePlatformSpecificTestOptionsForTest would be a better > > place to reset and set these values in NSUserDefaults. > > 2. Instead of setting the bool to NO, let's remove object for key. > > I don't think this will work because > updatePlatformSpecificTestOptionsForTest() is called before > updateTestOptionsFromTestHeader() in TestController::testOptionsForTest(), > so it doesn't have the updated value. Then I think > platformResetStateToConsistentValues is called at the end of the test, so I > can remove the key there but not set it prior to the test.
Maybe I'm missing something? Because it seems like all internal/experimental features are set before the header comments are read, and those seem to work fine. But this test still fails if I call it before updateTestOptionsFromTestHeader().
Brent Fulgham
Comment 9
2020-04-13 14:18:36 PDT
r=me
EWS
Comment 10
2020-04-13 14:37:46 PDT
Committed
r260040
: <
https://trac.webkit.org/changeset/260040
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 396313
[details]
.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug