-
Notifications
You must be signed in to change notification settings - Fork 974
Using scroll-touch-edge to record the distance #15128
Conversation
Update master to 0.25.0
Fix some error branches in tor controller logic.
This should address the failure reported in: #14675 (comment) fix #14630 Auditors: @diracdeltas Test Plan: see #14630
This, and TorControl.destroy(), are worth making idempotent because errors may happen synchronously _or_ asynchronously, so there are two levels at which a caller might want to clean up. For example, authentication failure is reported as a 515 error from tor, _and_ the tor daemon will close the control connection leading to an asynchronous error.
There is no way to know exactly when this might happen, alas: readables and writables don't necessarily emit their close events promptly.
for some reason, the windows path has an extra `../` prefix compared to mac so the favicon doesn't load. this works around the issue by removing a `../` on windows. Test Plan: 1. open new tab 2. hit `:g` in the urlbar 3. the search favicon should load on all platforms
…es-v2 Fix some more error branches, assert sanity, and automatically test it all.
This was always signing the RPM because the test was failing, now we will test and if the signature exists then move on. The error seen was: tools/upload_to_rpm_repo: line 18: !rpm: command not found
fix search favicon path on windows
…ut key for new private tab Fixes #14504 Auditors: @diracdeltas
Fix #14680 Test Plan: 1. open brave, turn on showing bookmarks toolbar and showing home button in about:preferences. bookmark some sites. 2. open tor tab and try to click on bookmarks before tor finishes loading. also try clicking on the home button and clicking the History > Home menu item. 3. these loads should be blocked until tor finishes initializing
Add shortcut for private tab with Tor and also update existing shortc…
Allow upload script to check if current signature exists.
Block tab.loadURL in tor tabs until tor is initialized
fix #14653 for some reason, renaming the searx favicon to something that doesn't have 'searx' in the filename makes it reappear Test Plan: 1. make a packaged build 2. open brave 3. hit ':x' in urlbar. searx favicon should appear.
Fix mysterious searx favicon disappearing in builds
Update to Muon 7.1.6
To do this, we separate step of killing the daemon and control channel from the step of ceasing to watch for updates. On errors, we want to kill the daemon and control channel, but continue watching for updates in case the daemon restarts. Possible snag: we do not rate-limit failures if they are recursive. Not currently an issue but we should take care of this in the future.
fix #14431 Auditors: @diracdeltas @bsclifton Test Plan: I: 1. Open a tab _without_ Tor (private or nonprivate). 2. Enter: https://nyttips4bmquxfzw.onion/ 3. Confirm that Brave blocks loading the URL. II: 1. Open a tab _without_ Tor (private or nonprivate). 2. Enter: https://nyttips4bmquxfzw.onion:12345/ 3. Confirm that Brave blocks loading the URL. III: 1. Open a private tab with Tor. 2. Enter: https://nyttips4bmquxfzw.onion/ 3. Confirm that the NYT SecureDrop page loads. 4. Bookmark it. 5. Open a tab _without_ Tor (private or nonprivate). 6. Try to load the bookmark. 7. Confirm that Brave blocks loading the bookmark.
Don't emit an 'error' event if we did pass them synchronously. Establish an 'error' handler in filtering.js for asynchronous errors.
Removes delay for referral
fix #15074 Test Plan: DM'ed
block chrome://brave URL loads
Fixes #15075 Auditors: @diracdeltas
Allow `view-source` as openable by context menu
Resolves #15073 Auditors: Test Plan:
Removes shadow
fix typo in test description: deafult -> default
fix typo in js extension comment: occuring -> occurring
Release notes for 0.23.x Release 5
Update to Muon 8.0.9
only fire once each scroll since C69 mainly fix #15114 also fix #14871 fix #14829 fix #14785 Auditor: @bsclifton
don't merge it until master has C69 muon |
I believe this logic is broken. If I swipe right on the trackpad with the intention of navigating backwards, 1) the sensitivity is incredibly high, but 2) if i change directions on horizontal scroll and try to "change my mind" and scroll back the other way, your deltaX keeps increasing since I haven't lifted my fingers |
I can go ahead and create some changes on top of this PR if you'd like? |
no, this is because require chromium 69 which is in 8.1.x. So we have to wait for master upgrading muon version so we can test this PR and merge it |
for now, you can try 0.23.x-c69 branch. And create a PR on top of it if you want |
app/renderer/components/main/main.js
Outdated
} else { | ||
appActions.swipedRight(percent) | ||
} | ||
deltaX += 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the intended purpose of this line and line 276? that seems to cause the issue i mentioned in the discussion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
again, that is intentional for features::kTouchpadAndWheelScrollLatching
enabled in c69 and master does't have the compatible version of muon now.
could you try 0.23.x-c69 branch first?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea, still broken off of 0.23.x-c69 branch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did you delete node_modules/electron-prebuilt
and redo a npm install?
If you didn't, that means you don't have the correct muon version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can also try https://github.com/brave/browser-laptop/releases/tag/v0.23.202beta which is just built from that branch and contains this fix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes i rm rf'd node modules on the 0.23.x-c69
branch and the issue still occurs. Also the issue i mentioned still occurs in https://github.com/brave/browser-laptop/releases/tag/v0.23.202beta
would you like me to try to fix?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the problem you talked about is no way to cancel the navigation once you reach 100%. you can try to fix that. But I don't see so called incredibly high sensitivity
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to emit more attributes from muon for this event so I can update the precise units
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can try 0.23.x-c69 again now. new muon build is ready
depends on brave/muon@b9cec60 Auditors: @bsclifton
Closing as |
cause wheel event will only fire once each scroll since C69
mainly
fix #15114
also
fix #14871
fix #14829
fix #14785
Auditor: @bsclifton
Submitter Checklist:
git rebase -i
to squash commits (if needed).Test Plan:
Reviewer Checklist:
Tests