1. 05 Dec, 2019 1 commit
  2. 18 Nov, 2019 1 commit
  3. 04 Nov, 2019 1 commit
  4. 06 Nov, 2019 1 commit
  5. 28 Oct, 2019 1 commit
  6. 18 Oct, 2019 1 commit
  7. 11 Oct, 2019 1 commit
  8. 09 Oct, 2019 4 commits
  9. 24 Sep, 2019 4 commits
  10. 20 Sep, 2019 1 commit
  11. 07 Aug, 2019 1 commit
  12. 16 Jul, 2019 1 commit
  13. 26 Jul, 2019 1 commit
  14. 16 Jul, 2019 2 commits
  15. 25 Jun, 2019 1 commit
  16. 12 Jun, 2019 2 commits
  17. 03 Jun, 2019 1 commit
  18. 23 May, 2019 1 commit
    • Barret Rennie's avatar
      Bug 1510569 - Keep track of whether we are navigating to a new URI in... · 03450835
      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
      03450835
  19. 22 May, 2019 1 commit
  20. 21 May, 2019 5 commits
    • Christoph Kerschbaumer's avatar
      Bug 965637: Move CSP from Principal into Client, part 1: backend changes. r=mccr8 · b6334273
      Christoph Kerschbaumer authored
      Differential Revision: https://phabricator.services.mozilla.com/D27654
      
      --HG--
      extra : moz-landing-system : lando
      b6334273
    • Noemi Erli's avatar
      Backed out 4 changesets (bug 1510569) for mass test failures CLOSED TREE · cc1f5b44
      Noemi Erli authored
      Backed out changeset c5488e2770a6 (bug 1510569)
      Backed out changeset df98eef1f640 (bug 1510569)
      Backed out changeset db6da7f94a92 (bug 1510569)
      Backed out changeset fb696b92c13d (bug 1510569)
      cc1f5b44
    • 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
    • Cosmin Sabou's avatar
      Backed out 4 changesets (bug 1510569) for causing build bustages on nsIDocShell.idl CLOSED TREE · e565aa82
      Cosmin Sabou authored
      Backed out changeset 57f49df057be (bug 1510569)
      Backed out changeset de97a258fcfd (bug 1510569)
      Backed out changeset 4b0ed20ab3bc (bug 1510569)
      Backed out changeset 1d8ab383d3e9 (bug 1510569)
      e565aa82
    • Barret Rennie's avatar
      Bug 1510569 - Keep track of whether we are navigating to a new URI in... · 3ee6a359
      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
      3ee6a359
  21. 08 May, 2019 1 commit
  22. 27 May, 2019 2 commits
  23. 26 Apr, 2019 1 commit
  24. 03 May, 2019 1 commit
  25. 02 May, 2019 3 commits
    • Barret Rennie's avatar
      Bug 1510569 - Keep track of whether we are navigating to a new URI in... · c28096b9
      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
      c28096b9
    • Bogdan Tara's avatar
      Backed out 2 changesets (bug 1510569) for crashtests/1419902.html failures CLOSED TREE · 86cbef62
      Bogdan Tara authored
      Backed out changeset 13c5249d66a7 (bug 1510569)
      Backed out changeset a6ad4039d785 (bug 1510569)
      86cbef62
    • Barret Rennie's avatar
      Bug 1510569 - Keep track of whether we are navigating to a new URI in... · 5474c1f3
      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
      5474c1f3