WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
177714
XMLHttpRequest's responseXML should be annotated with [Exposed=Window]
https://bugs.webkit.org/show_bug.cgi?id=177714
Summary
XMLHttpRequest's responseXML should be annotated with [Exposed=Window]
Sam Weinig
Reported
2017-09-30 20:56:14 PDT
XMLHttpRequest's responseXML should be annotated with [Exposed=Window]
Attachments
Patch
(1.21 KB, patch)
2017-09-30 20:56 PDT
,
Sam Weinig
no flags
Details
Formatted Diff
Diff
Patch
(5.28 KB, patch)
2017-10-01 03:48 PDT
,
Sam Weinig
no flags
Details
Formatted Diff
Diff
Patch
(3.07 KB, patch)
2017-10-01 08:20 PDT
,
Sam Weinig
buildbot
: commit-queue-
Details
Formatted Diff
Diff
Archive of layout-test-results from ews102 for mac-elcapitan
(1.03 MB, application/zip)
2017-10-01 09:25 PDT
,
Build Bot
no flags
Details
Patch
(9.96 KB, patch)
2017-10-01 09:42 PDT
,
Sam Weinig
no flags
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Sam Weinig
Comment 1
2017-09-30 20:56:46 PDT
Created
attachment 322309
[details]
Patch
Alexey Proskuryakov
Comment 2
2017-09-30 22:01:59 PDT
Comment on
attachment 322309
[details]
Patch Is this not testable?
Sam Weinig
Comment 3
2017-10-01 02:45:53 PDT
(In reply to Alexey Proskuryakov from
comment #2
)
> Comment on
attachment 322309
[details]
> Patch > > Is this not testable?
Yes. I was hoping there was already a test and it would fail (hence the no r?) but it looks like I’ll have to write one.
Sam Weinig
Comment 4
2017-10-01 03:48:25 PDT
Created
attachment 322317
[details]
Patch
Sam Weinig
Comment 5
2017-10-01 07:32:03 PDT
(In reply to Sam Weinig from
comment #3
)
> (In reply to Alexey Proskuryakov from
comment #2
) > > Comment on
attachment 322309
[details]
> > Patch > > > > Is this not testable? > > Yes.
By which of course I mean, “yes, it is testable” (double negative caught me). Last WIP adds the test. I’m surprised that not having a result didn’t cause the EWS to fail.
Sam Weinig
Comment 6
2017-10-01 07:33:02 PDT
(In reply to Sam Weinig from
comment #5
)
> (In reply to Sam Weinig from
comment #3
) > > (In reply to Alexey Proskuryakov from
comment #2
) > > > Comment on
attachment 322309
[details]
> > > Patch > > > > > > Is this not testable? > > > > Yes. > > By which of course I mean, “yes, it is testable” (double negative caught > me).
Ahhhh. I meant negative not double negative!
Sam Weinig
Comment 7
2017-10-01 08:20:33 PDT
Created
attachment 322319
[details]
Patch
Sam Weinig
Comment 8
2017-10-01 08:51:01 PDT
Filed
https://github.com/w3c/web-platform-tests/pull/7530
to add the new tests to WPT.
Build Bot
Comment 9
2017-10-01 09:25:11 PDT
Comment hidden (obsolete)
Comment on
attachment 322319
[details]
Patch
Attachment 322319
[details]
did not pass mac-ews (mac): Output:
http://webkit-queues.webkit.org/results/4715745
New failing tests: fast/xmlhttprequest/xmlhttprequest-responseXML-in-worker.html
Build Bot
Comment 10
2017-10-01 09:25:12 PDT
Comment hidden (obsolete)
Created
attachment 322320
[details]
Archive of layout-test-results from ews102 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews102 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Sam Weinig
Comment 11
2017-10-01 09:42:44 PDT
Created
attachment 322321
[details]
Patch
Sam Weinig
Comment 12
2017-10-01 09:43:42 PDT
(In reply to Sam Weinig from
comment #11
)
> Created
attachment 322321
[details]
> Patch
New patch includes the now landed WPTs, imported back into WebKit.
Alexey Proskuryakov
Comment 13
2017-10-01 12:42:02 PDT
> I’m surprised that not having a result didn’t cause the EWS to fail.
Please feel encouraged to file a bug! I think that's a pretty bad issue.
Sam Weinig
Comment 14
2017-10-01 12:45:01 PDT
(In reply to Alexey Proskuryakov from
comment #13
)
> > I’m surprised that not having a result didn’t cause the EWS to fail. > > Please feel encouraged to file a bug! I think that's a pretty bad issue.
Ok.
https://bugs.webkit.org/show_bug.cgi?id=177723
.
Darin Adler
Comment 15
2017-10-01 13:45:10 PDT
Comment on
attachment 322321
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=322321&action=review
> Source/WebCore/xml/XMLHttpRequest.cpp:175 > + ASSERT(scriptExecutionContext()->isDocument());
I would write: ASSERT(is<Document>(scriptExecutionContext())); But I see the file already has three places that do it the other way, calling isDocument().
> Source/WebCore/xml/XMLHttpRequest.cpp:257 > + if (!scriptExecutionContext()->isDocument() && type == ResponseType::Document) > + return { };
As I said above, I like the is<Document> style better. If you wrote it is<Document>(scriptExecutionContext() then you would include an unnecessary null check. But it’s annoying that the assumption that script execution context is non-null is implicit; when called from script I guess that is sort of obvious, but on the other hand it’s annoying that it’s called “script execution context” yet we stash it when created and don’t get a fresh one when being called from script again. I kind of wish there was a version that returned a reference and asserted.
WebKit Commit Bot
Comment 16
2017-10-01 14:12:52 PDT
Comment on
attachment 322321
[details]
Patch Clearing flags on attachment: 322321 Committed
r222690
: <
http://trac.webkit.org/changeset/222690
>
WebKit Commit Bot
Comment 17
2017-10-01 14:12:54 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 18
2017-10-01 14:13:47 PDT
<
rdar://problem/34761304
>
Sam Weinig
Comment 19
2017-10-01 18:37:19 PDT
Add missing test results in
r222693
.
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