Skip to content
GitLab
Switch branch/tag
  1. 05 Dec, 2019 1 commit
  3. 18 Nov, 2019 1 commit
  5. 04 Nov, 2019 1 commit
  7. 06 Nov, 2019 1 commit
  9. 28 Oct, 2019 1 commit
  11. 18 Oct, 2019 1 commit
  13. 11 Oct, 2019 1 commit
  15. 09 Oct, 2019 4 commits
  17. 24 Sep, 2019 4 commits
  19. 20 Sep, 2019 1 commit
  21. 07 Aug, 2019 1 commit
  23. 16 Jul, 2019 1 commit
  25. 26 Jul, 2019 1 commit
  27. 16 Jul, 2019 2 commits
  29. 25 Jun, 2019 1 commit
  31. 12 Jun, 2019 2 commits
  33. 03 Jun, 2019 1 commit
  35. 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
  37. 22 May, 2019 1 commit
  39. 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
  41. 08 May, 2019 1 commit
  43. 27 May, 2019 2 commits
  45. 26 Apr, 2019 1 commit
  47. 03 May, 2019 1 commit
  49. 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