1. 13 Feb, 2020 3 commits
  2. 12 Feb, 2020 14 commits
  3. 11 Feb, 2020 16 commits
  4. 10 Feb, 2020 7 commits
    • Gabriel Luong's avatar
    • MozLando's avatar
      Merge #5850 · 9d35a669
      MozLando authored
      
      
      5850: Closes #5692: NotImplementedError: Octet length not supported r=grigoryk a=st3fan
      
      This patch for #5692   fixes a integer sign issue when pulling bytes with the high bit set out of a `ByteArray`. I also fixed a bug where 3-byte lengths were not correctly decoded. (Unclear how likely it is that we encounter a login item that is larger than 2^16 though.)
      
      I was not sure how to write a test for the embedded `ByteArray.getEncodingLength` so I actually pulled that extension method out of the `FennecLoginsMigration` class. Let me know if there is an elegant solution for that.
      
      Draft because I'll add a few more test cases with funny numbers.
      
      
      
      Co-authored-by: default avatarStefan Arentz <stefan@arentz.ca>
      9d35a669
    • Gabriel Luong's avatar
    • Christian Sadilek's avatar
    • Roger Yang's avatar
      2573407b
    • MozLando's avatar
      Merge #5738 · 5914f63a
      MozLando authored
      5738: Refactor to decouple WebExtensions from the engine architecture r=csadilek a=keianhzo
      
      Closes #5735 Closes #5736 Closes #5737
      
      The purpose of this task is to expose the `WebExtensions` features in a a more `concept-engine` architecture agnostic way. 
      
      The Web Extensions implementation is coupled to the concept-engine/browser-session architecture. Some projects would prefer to have their own engine/session implementation but still be able to use modules from AC like the Web Extensions features. This is the case for Firefox Reality where we need a very specific engine/session implementation.
      
      WebExtensions shouldn't require much from Engine/Session as at the moment. They just use the runtime and the session from the inner engine implementations and in some cases might require session life cycle related callbacks to register handlers. We sould be able to refactor all the WebExtension realated code out of `Engine` and `EngineSession` and ideally also remove from the WebExtensions any dependency from session life cycle related classes like `SelectionAwareSessionObserver` or `LifecycleAwareFeature`.
      
      I've made a basic refactor proposal based on the reported issues. You can take look at it in this PR.
      - Added a new `WebExtensionEngine` interface that provides all the WebExtensions required functionality: `installWebExtension`, `updateWebExtension`, etc. to limit the required code to add support for AC Web Extensions.
      - Add a new `WebExtensionEngineSession` interface that provides access to the inner browser session as that's the one thing that Web Extensions require at the moment.
      - Make `Engine` and `EngineSession` implement `WebExtensionEngine` and `WebExtensionEngineSession`.
      - Updated `FxaWebChannelFeature` so `SessionManager` is an optional parameter and decouple it's implementation from it so they life cycle callbacks can be handled independently.
      - Updating the AC codebase to follow the new pattern.
      
      Things not yet covered by this proposal:
      - [ ] Completely decouple the extensions from `SessionManager` and `SelectionAwareSessionObserver`.
      - [ ] Follow the same pattern for other Web Extension features like `ReaderViewFeature`.
      - [ ] Update tests and fix CI issues
      - [ ] Refactor all the WebExtensions related code from `concept-engine` into support-webextensions?
      - [ ] Probably a bunch of things that I've missed
      
      If this look like a good initial step, I can keep on working on it. Otherwise you can close it and and we can discuss the opened issues to see what would be the right way to go to make AC Web Extensions to work for any GV based project.
      
      <!-- Text above this line will be added to the commit once "bors" merges this PR -->
      
      ### Pull Request checklist
      <!-- Before submitting the PR, please address each item -->
      - [x] **Quality**: This PR builds and passes detekt/ktlint checks (A pre-push hook is recommended)
      - [x] **Tests**: This PR includes thorough tests or an explanation of why it does not
      - [x] **Changelog**: This PR includes [a changelog entry](https://github.com/mozilla-mobile/android-components/blob/master/docs/changelog.md) or does not need one
      - [x] **Accessibility**: The code in this PR follows [accessibility best practices](https://github.com/mozilla-mobile/shared-docs/blob/master/android/accessibility_guide.md) or does not include any user facing features
      
      ### After merge
      - [ ] **Milestone**: Make sure issues closed by this pull request are added to the [milestone](https://github.com/mozilla-mobile/android-components/milestones) of the version currently in development.
      - [ ] **Breaking Changes**: If this is a breaking change, please push a draft PR on [Reference Browser](https://github.com/mozilla-mobile/reference-browser
      
      ) to address the breaking issues.
      
      
      Co-authored-by: default avatarManuel Martin <manmartin@mozilla.com>
      5914f63a
    • MozLando's avatar
      Merge #5872 · da7fe6a8
      MozLando authored
      
      
      5872: Annotate breaking API on Awesomebar changes [ci skip] r=pocmo a=jonalmeida
      
      
      
      Co-authored-by: default avatarJonathan Almeida <jalmeida@mozilla.com>
      da7fe6a8