1. 21 May, 2019 8 commits
    • Erica Wright's avatar
      Bug 1549825 - Create empty about:protections page. r=johannh,baku · c20fb3ba
      Erica Wright authored
      Differential Revision: https://phabricator.services.mozilla.com/D30652
      
      --HG--
      extra : moz-landing-system : lando
      c20fb3ba
    • Barret Rennie's avatar
      Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag · 461c1d28
      Barret Rennie authored
      We now also only access the document when the state is
      nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
      touching the document inside the event handler when the state is not STATE_STOP
      would result in the content creating a new about:blank document to retrieve the
      values from. However, it then went on to do this in another location, causing a
      document to be created whenever we received an onStateChange event. This should
      no longer occur.
      
      Differential Revision: https://phabricator.services.mozilla.com/D28125
      
      --HG--
      extra : moz-landing-system : lando
      461c1d28
    • Barret Rennie's avatar
      Bug 1510569 - Keep track of whether we are navigating to a new URI in... · 68cdb085
      Barret Rennie authored
      Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot
      
      Previously the `WebNavigationChild` would keep track of when triggering its
      `nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
      It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
      porting `OnStateChange` and `OnLocationChange` events from
      `WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
      informations needs to be available from the `BrowserChild`. As it stands, it is
      currently an expando property on the `WebProgressChild`.
      
      Instead of introducing yet another XPCOM interface for the WebProgressChild, we
      now store this information directly on the `nsDocShell`. Furthermore, instead
      of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
      state, we can have the `nsDocShell` manage this state itself so it is always
      consistent.
      
      Differential Revision: https://phabricator.services.mozilla.com/D28124
      
      --HG--
      extra : moz-landing-system : lando
      68cdb085
    • Barret Rennie's avatar
      Bug 1510569 - Refactor BrowserParent nsIWebProgress handlers r=kmag · 8dc24e13
      Barret Rennie authored
      The BrowserParent's IPC receive methods for nsIWebProgress events in the
      BrowserChild were all doing the same set up to ensure they had the correct
      state to process them. This has now been refactored out into a single method.
      
      Differential Revision: https://phabricator.services.mozilla.com/D30730
      
      --HG--
      extra : moz-landing-system : lando
      8dc24e13
    • Barret Rennie's avatar
      Bug 1510569 - Only forward nsIWebProgress events to the BrowserParent after... · f03d70b7
      Barret Rennie authored
      Bug 1510569 - Only forward nsIWebProgress events to the BrowserParent after the WebProgressChild has loaded r=kmag,mconley
      
      Before the WebProgress event handlers started migrating to C++, the parent
      process would only receive WebProgress events after the child process had
      finished loading the WebProgressChild script. Now that listeners are registered
      much earlier (before the BrowserChild has finished setting up its frame
      scripts), the BrowserParent would receive WebProgress events that were
      heretofore not received unless the BrowserChild was *very* careful about when
      it sent the IPC messages.
      
      However, even while being very careful, the OnStateChange event handler would
      always fire events for initial about:blank loads that break a lot of unit
      tests. Before porting that event, we are now ensuring that the WebProgressChild
      has finished loading before the BrowserChild will send IPC messages for these
      events to the BrowserParent.
      
      Differential Revision: https://phabricator.services.mozilla.com/D30252
      
      --HG--
      extra : moz-landing-system : lando
      f03d70b7
    • Olli Pettay's avatar
      Bug 1552958 - De-templatize PrioritizedEventQueue, r=froydnj · fa04ddd3
      Olli Pettay authored
      PrioritizedEventQueue's template is always EventQueue, so the template
      argument is rather useless.
      Trying to keep the patch minimal, so CreateMainThread for example is still
      a bit weird.
      
      Differential Revision: https://phabricator.services.mozilla.com/D31871
      
      --HG--
      extra : moz-landing-system : lando
      fa04ddd3
    • Emilio Cobos Álvarez's avatar
      Bug 1552719 - Bump an assertion count in the XBL + lists test, since we run... · 78aebf4d
      Emilio Cobos Álvarez authored
      Bug 1552719 - Bump an assertion count in the XBL + lists test, since we run the code that asserts more often now. r=bustage
      
      CLOSED TREE
      
      78aebf4d
    • Nathan Froyd's avatar
      Bug 1551690 - be more specific about the LLVM target on OS X; r=nalexander · 37d0db29
      Nathan Froyd authored
      Our current OS X builds use `--target=x86_64-darwin11` (which
      corresponds to OS X 10.7).  This target is problematic for two reasons:
      
      * We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
      * It's slightly different from the default Rust target.
      
      Let's address these problems in reverse order: differences from the Rust
      target are bad, because the `--target` we provide to `clang` and the
      Rust target find their way into LLVM bitcode files and the linker will
      refuse to link together bitcode files that have incompatible targets.
      
      Why are the two incompatible?  The current `--target` doesn't have a
      "vendor" in triple-speak, whereas the Rust one has "apple" as the
      vendor (`x86_64-apple-darwin`) We therefore need to change the
      `--target` we pass to `clang` to have a vendor of "apple".
      
      This need is behind the {init,toolchain}.configure changes,
      but it has ramifications elsewhere, because `clang` looks for
      `--target`-prefixed build tools.  So we have to change the `--target`
      for cctools to get the right tool prefixes and we have to change the
      `--target` for building clang ourselves so that *those* builds can find
      the newly renamed cctools.
      
      Once we've done, that's really enough; we don't *need to address the
      first problem: While the `--target` might be `x86_64-apple-darwin11`,
      both `clang` and `rustc` will dynamically choose the target triple that
      eventually lands in LLVM bitcode files based on
      `MACOSX_DEPLOYMENT_TARGET`, which we set in all builds.  But the current
      target is slightly misleading, and the cctools don't need to be prefixed
      with a particular Darwin version, since they work for all Darwin
      targets.  Let's just drop the "11" from the `--target` and eliminate a
      little bit of confusion.
      
      Differential Revision: https://phabricator.services.mozilla.com/D31128
      
      --HG--
      extra : moz-landing-system : lando
      37d0db29
  2. 20 May, 2019 1 commit
  3. 21 May, 2019 31 commits