1. 09 Oct, 2019 1 commit
  2. 08 Oct, 2019 1 commit
  3. 07 Oct, 2019 1 commit
  4. 03 Oct, 2019 1 commit
  5. 08 Oct, 2019 2 commits
    • Tom Ritter's avatar
      Bug 1583949 - Add a check for IsEvalAllowed to the worker callpath for eval() r=ckerschb,baku · 23ba7b6f
      Tom Ritter authored
      This patch does several things.  Because Workers aren't on the main thread,
      many of the things done are in the name of off main thread access.
      
      1) Changes a parameter in IsEvalAllowed from a nsIPrincipal to a bool.
         We only used the principal to determined if it was the System Principal.
         Principals aren't thread safe and can only be accessed on Main Thread, so
         if we passed a Principal in, we would be in error. Instead only pass in
         the bool which - for workers - comes from a thread-safe location.
      
      2) Separates out the Telemetry Event Recording and sending a message to the
         console into a new function nsContentSecurityUtils::NotifyEvalUsage. (And
         creates a runnable that calls it.)
      
         We do this because we will need to only call this method on the main thread.
      
         Telemetry Event Recording has only ever been called on the Main Thread.
         While I possibly-successfully cut it over to happen Off Main Thread (OMT)
         by porting preferences to StaticPrefs, I don't know if there were other
         threading assumptions in the Telemetry Code. So it would be much safer to
         just continue recording Event Telemetry on the main thread.
      
         Sending a message to the console requires calling GetStringBundleService()
         which requires main thread. I didn't investigate if this could be made
         thread-safe, I just threw it onto the main thread too.
      
         If, in IsEvalAllowed, we are on the main thread - we call NotifyEvalUsage
         directly. If we are not, we create a runnable which will then call
         NotifyEvalUsage for us on the main thread.
      
      3) Ports allow_eval_with_system_principal and allow_eval_in_parent_process
         from bools to RelaxedAtomicBool - because we now check these prefs OMT.
      
      4) In RuntimeService.cpp, adds the call to IsEvalAllowed.
      
      5) Add resource://gre/modules/workers/require.js to the allowlist of eval
         usage. This was the script that identified this gap in the first place.
         It uses eval (twice) for structural reasons (scope and line number
         massaging.)  The contents of the eval are the result of a request to a
         uri (which may be internal, like resource://). The whole point of this
         is to implement a CommonJS require() api.
      
         This usage of eval is safe because the only way an attacker can inject
         into it is by either controlling the response of the uri request or
         controlling (or appending to) the argument. If they can do that, they
         are able to inject script into Firefox even if we cut this usage of eval
         over to some other type of safe(r) script loader.
      
         Bug 1584564 tracks making sure calls to require.js are safe.
      
      6) Adds cld-worker.js to the allowlist. Bug 1584605 is for refactoring that
         eval usage, which is decidedly non-trivial.
      
      7) Does _not_ enforce the eval restrictions for workers. While I've gotten
         try to be green and not throw up any instances of eval-usage by workers,
         it is much safer to deploy this is Telemetry-only mode for Workers for
         a little bit to see if anything pops up from the Nightly population.
      
         Bug 1584602 is for enforcing the checks.
      
      Differential Revision: https://phabricator.services.mozilla.com/D47480
      
      --HG--
      extra : moz-landing-system : lando
      23ba7b6f
    • John Lin's avatar
      Bug 1581902 - p6: introduce a pref to enable/disable H.264 for WebRTC. r=pehrsons · 2341df44
      John Lin authored
      Differential Revision: https://phabricator.services.mozilla.com/D46368
      
      --HG--
      extra : moz-landing-system : lando
      2341df44
  6. 07 Oct, 2019 3 commits
  7. 05 Oct, 2019 1 commit
  8. 07 Oct, 2019 1 commit
  9. 01 Oct, 2019 1 commit
  10. 04 Oct, 2019 3 commits
  11. 03 Oct, 2019 1 commit
  12. 30 Sep, 2019 1 commit
  13. 26 Sep, 2019 1 commit
  14. 03 Oct, 2019 1 commit
  15. 02 Oct, 2019 3 commits
    • Frederic Wang's avatar
      Bug 1548522 - Remove support for the menclose's "radical" notation. r=emilio · 8a93c86e
      Frederic Wang authored
      See https://groups.google.com/forum/#!topic/mozilla.dev.platform/vwAkuZIEhnY
      
      * Introduce a new preference option to disable menclose's "radical" notation.
      * Disable the notation in Nightly and when running WPT tests.
      * Enable the notation in other channels together with a counter and
        deprecation warning.
      * Update WPT test legacy-menclose-radical-notation.html
        - Fix test: "radical" should be equivalent to "", which is not the same as
          the default value "longdiv".
          See https://github.com/mathml-refresh/mathml/issues/144
        - Add a test "box radical" which should be equivalent to "box".
        - Remove failure expectation.
      * Enable the radical notation for MathML reftests testing it.
      
      Differential Revision: https://phabricator.services.mozilla.com/D46721
      
      --HG--
      extra : moz-landing-system : lando
      8a93c86e
    • Emilio Cobos Álvarez's avatar
      Bug 1585637 - Turn on layout.css.width-and-height-map-to-aspect-ratio.enabled... · 3a164c3f
      Emilio Cobos Álvarez authored
      Bug 1585637 - Turn on layout.css.width-and-height-map-to-aspect-ratio.enabled on late beta and release. r=dholbert
      
      Differential Revision: https://phabricator.services.mozilla.com/D47902
      
      --HG--
      extra : moz-landing-system : lando
      3a164c3f
    • Dzmitry Malyshau's avatar
      Bug 1581710 - Update WebGPU IDL bindings r=jgilbert,bzbarsky · b91906ee
      Dzmitry Malyshau authored
      This mostly updates the bindings to the current state.
      No actual logic backing them yet.
      
      *Note*: the IDL does *not* need to be checked for matching the upstream spec precisely at this stage. The upstream is evolving, we just need to update in order to start integrating the implementation. What needs to be checked is - how C++ represents the IDL, esp with regards to derived classes, events, and hierarchies.
      
      The trickiest points, arguably, are:
        - WebGPU -> GPU prefix change
        - the goop for interfaces that are not final
      
      Differential Revision: https://phabricator.services.mozilla.com/D46166
      
      --HG--
      rename : dom/webgpu/InputState.cpp => dom/webgpu/DeviceLostInfo.cpp
      rename : dom/webgpu/Fence.h => dom/webgpu/DeviceLostInfo.h
      rename : dom/webgpu/BlendState.cpp => dom/webgpu/OutOfMemoryError.cpp
      rename : dom/webgpu/LogEntry.h => dom/webgpu/OutOfMemoryError.h
      rename : dom/webgpu/BindGroup.h => dom/webgpu/ProgrammablePassEncoder.cpp
      rename : dom/webgpu/BlendState.cpp => dom/webgpu/RenderBundle.cpp
      rename : dom/webgpu/BlendState.h => dom/webgpu/RenderBundle.h
      rename : dom/webgpu/AttachmentState.cpp => dom/webgpu/ValidationError.cpp
      rename : dom/webgpu/AttachmentState.h => dom/webgpu/ValidationError.h
      extra : moz-landing-system : lando
      b91906ee
  16. 30 Sep, 2019 1 commit
  17. 28 Sep, 2019 1 commit
  18. 02 Oct, 2019 2 commits
    • Brindusan Cristian's avatar
      Backed out changeset 1ca9b7056c58 (bug 1581710) for mochitest failures at... · 84164522
      Brindusan Cristian authored
      Backed out changeset 1ca9b7056c58 (bug 1581710) for mochitest failures at test_enabled.html. CLOSED TREE
      
      --HG--
      rename : dom/webgpu/ValidationError.cpp => dom/webgpu/AttachmentState.cpp
      rename : dom/webgpu/ValidationError.h => dom/webgpu/AttachmentState.h
      rename : dom/webgpu/RenderBundle.cpp => dom/webgpu/BlendState.cpp
      rename : dom/webgpu/RenderBundle.h => dom/webgpu/BlendState.h
      rename : dom/webgpu/DeviceLostInfo.cpp => dom/webgpu/InputState.cpp
      rename : dom/webgpu/OutOfMemoryError.h => dom/webgpu/LogEntry.h
      84164522
    • Dzmitry Malyshau's avatar
      Bug 1581710 - Update WebGPU IDL bindings r=jgilbert,bzbarsky · 06892759
      Dzmitry Malyshau authored
      This mostly updates the bindings to the current state.
      No actual logic backing them yet.
      
      *Note*: the IDL does *not* need to be checked for matching the upstream spec precisely at this stage. The upstream is evolving, we just need to update in order to start integrating the implementation. What needs to be checked is - how C++ represents the IDL, esp with regards to derived classes, events, and hierarchies.
      
      The trickiest points, arguably, are:
        - WebGPU -> GPU prefix change
        - the goop for interfaces that are not final
      
      Differential Revision: https://phabricator.services.mozilla.com/D46166
      
      --HG--
      rename : dom/webgpu/InputState.cpp => dom/webgpu/DeviceLostInfo.cpp
      rename : dom/webgpu/Fence.h => dom/webgpu/DeviceLostInfo.h
      rename : dom/webgpu/BlendState.cpp => dom/webgpu/OutOfMemoryError.cpp
      rename : dom/webgpu/LogEntry.h => dom/webgpu/OutOfMemoryError.h
      rename : dom/webgpu/BindGroup.h => dom/webgpu/ProgrammablePassEncoder.cpp
      rename : dom/webgpu/BlendState.cpp => dom/webgpu/RenderBundle.cpp
      rename : dom/webgpu/BlendState.h => dom/webgpu/RenderBundle.h
      rename : dom/webgpu/AttachmentState.cpp => dom/webgpu/ValidationError.cpp
      rename : dom/webgpu/AttachmentState.h => dom/webgpu/ValidationError.h
      extra : moz-landing-system : lando
      06892759
  19. 01 Oct, 2019 2 commits
  20. 27 Sep, 2019 3 commits
  21. 13 Sep, 2019 1 commit
  22. 27 Sep, 2019 5 commits
  23. 25 Sep, 2019 1 commit
  24. 23 Sep, 2019 1 commit
  25. 24 Sep, 2019 1 commit