Closed Bug 1116624 Opened 5 years ago Closed 5 years ago

Consider moving CORS into dom/security

Categories

(Core :: DOM: Security, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla37

People

(Reporter: ckerschb, Assigned: ckerschb)

Details

Attachments

(1 file)

Since we have ContentSecurityPolicy, MixedContentBlocker and soon SubResourceIntegrity (Bug 992096) in dom/security I think it also makes sense to move CORS into dom/security.
Attached patch move_cors.patchSplinter Review
Attachment #8542745 - Flags: review?(jonas)
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Comment on attachment 8542745 [details] [diff] [review]
move_cors.patch

>diff --git a/dom/base/moz.build b/dom/base/moz.build
>@@ -240,17 +239,16 @@ UNIFIED_SOURCES += [
>     'nsCCUncollectableMarker.cpp',
>     'nsContentAreaDragDrop.cpp',
>     'nsContentIterator.cpp',
>     'nsContentList.cpp',
>     'nsContentPermissionHelper.cpp',
>     'nsContentPolicy.cpp',
>     'nsContentSink.cpp',
>     'nsCopySupport.cpp',
>-    'nsCrossSiteListenerProxy.cpp',

Does it need to be added to UNIFIED_SOURCES on the dom/security side?


Even better is of course once callsites don't need to invoke these classes directly, but can just set a flag in the loadinfo. But that's of course a much different separate step.

This looks great!
Attachment #8542745 - Flags: review?(jonas) → review+
(In reply to Jonas Sicking (:sicking) from comment #2)
> Comment on attachment 8542745 [details] [diff] [review]
> move_cors.patch
> 
> >diff --git a/dom/base/moz.build b/dom/base/moz.build
> >@@ -240,17 +239,16 @@ UNIFIED_SOURCES += [
> >     'nsCCUncollectableMarker.cpp',
> >     'nsContentAreaDragDrop.cpp',
> >     'nsContentIterator.cpp',
> >     'nsContentList.cpp',
> >     'nsContentPermissionHelper.cpp',
> >     'nsContentPolicy.cpp',
> >     'nsContentSink.cpp',
> >     'nsCopySupport.cpp',
> >-    'nsCrossSiteListenerProxy.cpp',
> 
> Does it need to be added to UNIFIED_SOURCES on the dom/security side?

Not sure I understand the question, are you asking whether I forgot to add it to dom/security/moz.build, because I added it there. Or are you asking whehter we need it there, because we need it :-)
 
> Even better is of course once callsites don't need to invoke these classes
> directly, but can just set a flag in the loadinfo. But that's of course a
> much different separate step.

Soon Jonas, soon!
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #3)
> Not sure I understand the question, are you asking whether I forgot to add
> it to dom/security/moz.build, because I added it there. Or are you asking
> whehter we need it there, because we need it :-)

My bad. I retract my comment.

> > Even better is of course once callsites don't need to invoke these classes
> > directly, but can just set a flag in the loadinfo. But that's of course a
> > much different separate step.
> 
> Soon Jonas, soon!

Patience is not my strongest side :)
https://hg.mozilla.org/mozilla-central/rev/dcbe6ea33891
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.