Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

Enable Pocket/Password managers doesn't enable the extension #5934

Closed
srirambv opened this issue Nov 30, 2016 · 2 comments · Fixed by #12256
Closed

Enable Pocket/Password managers doesn't enable the extension #5934

srirambv opened this issue Nov 30, 2016 · 2 comments · Fixed by #12256
Labels
bug feature/extensions QA/checked-Win32 QA/checked-Win64 QA/test-plan-specified release-notes/exclude
Milestone
0.13.0

Comments

@srirambv
Copy link
Collaborator

srirambv commented Nov 30, 2016 •
edited
Loading

Did you search for similar issues before submitting this one?
Yes

Describe the issue you encountered:
Enable Pocket doesn't enable the extension

Expected behavior:
Should enable the pocket extension

  • Platform (Win7, 8, 10? macOS? Linux distro?):
    Windows 10 x64

  • Brave Version:
    0.13.0 preview 2

  • Steps to reproduce:

    1. Do a clean install of 0.13.0 preview 2
    2. Enable pocket from advance settings
    3. Pocket login tab doesn't launch, the widget is not loaded, about:extension doesn't have the entry for enabled extensions
    4. Enable 1Password/LastPass/Dashlane from the password manager, widget doesn't load, about:extension doesn't have the entry for the enabled password manager

  • Screenshot if needed:

  • Any related issues:
    cc: @jonathansampson @darkdh
@srirambv srirambv added this to the 0.13.0 milestone Nov 30, 2016
@srirambv srirambv changed the title Enable Pocket doesn't enable the extension Enable Pocket/Password managers doesn't enable the extension Nov 30, 2016
@srirambv
Copy link
Collaborator Author

cc: @bridiver

bridiver added a commit that referenced this issue Nov 30, 2016
@bridiver
ignore internal and extension generated requests
6023abd 
maybe fixes #5930
fix #5934

auditors: @bbondy
@darkdh
Copy link
Member

darkdh commented Dec 5, 2016

fixed by 6023abd

@darkdh darkdh closed this as completed Dec 5, 2016
bridiver added a commit that referenced this issue Dec 9, 2016
@bridiver
ignore internal and extension generated requests
4e0ee31 
maybe fixes #5930
fix #5934

auditors: @bbondy
posix4e pushed a commit that referenced this issue Dec 12, 2016
@bridiver @posix4e
ignore internal and extension generated requests
25c678e 
maybe fixes #5930
fix #5934

auditors: @bbondy
bridiver added a commit that referenced this issue Dec 14, 2016
@bridiver
ignore internal and extension generated requests
dd0a066 
maybe fixes #5930
fix #5934

auditors: @bbondy
This was referenced Dec 20, 2016
Closed
Closed
Closed
Closed
diracdeltas added a commit that referenced this issue Dec 12, 2017
@diracdeltas
Don't ignore internal requests in app/filtering
405b64a 
and return details.firstPartyUrl as a fallback for main frame URL.

Internal requests (tabId == -1) were ignored in order to fix #5934 in 6023abd. However (1) #5934 works without ignoring internal requests now and (2) generally speaking, non-webview requests should also be protected by HTTPS Everywhere, etc.

Test Plan:
1. confirm HTTPS Everywhere and Safebrowsing are working using the test plans in #12253 and #12252
2. confirm that #5934 has not regressed by enabling Pocket
diracdeltas added a commit that referenced this issue Dec 12, 2017
@diracdeltas
Don't ignore internal requests in app/filtering
09cbb1e 
and return details.firstPartyUrl as a fallback for main frame URL.

Internal requests (tabId == -1) were ignored in order to fix #5934 in 6023abd. However (1) #5934 works without ignoring internal requests now and (2) generally speaking, non-webview requests should also be protected by HTTPS Everywhere, etc.

fix #12253
fix #12252

Test Plan:
1. confirm HTTPS Everywhere and Safebrowsing are working using the test plans in #12253 and #12252
2. confirm that #5934 has not regressed by enabling Pocket
@diracdeltas diracdeltas mentioned this issue Dec 12, 2017
Merged
8 tasks
@bsclifton bsclifton mentioned this issue Dec 12, 2017
Merged
8 tasks
bsclifton pushed a commit that referenced this issue Dec 14, 2017
@diracdeltas @bsclifton
Don't ignore internal requests in app/filtering
3ec1fc4 
and return details.firstPartyUrl as a fallback for main frame URL.

Internal requests (tabId == -1) were ignored in order to fix #5934 in 6023abd. However (1) #5934 works without ignoring internal requests now and (2) generally speaking, non-webview requests should also be protected by HTTPS Everywhere, etc.

fix #12253
fix #12252

Test Plan:
1. confirm HTTPS Everywhere and Safebrowsing are working using the test plans in #12253 and #12252
2. confirm that #5934 has not regressed by enabling Pocket
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug feature/extensions QA/checked-Win32 QA/checked-Win64 QA/test-plan-specified release-notes/exclude
Projects
None yet
Milestone
0.13.0
Development

Successfully merging a pull request may close this issue.

Don't ignore internal requests in app/filtering
4 participants
@bbondy @luixxiul @darkdh @srirambv