Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mobile.twitter.com right click hang #2410

Closed
sudokai opened this issue Dec 7, 2018 · 9 comments · Fixed by brave/brave-core#2043
Closed

mobile.twitter.com right click hang #2410

sudokai opened this issue Dec 7, 2018 · 9 comments · Fixed by brave/brave-core#2043
Assignees
Labels
priority/P2 A bad problem. We might uplift this to the next planned release. QA Pass-Linux QA Pass-macOS QA Pass-Win64 QA/Test-Plan-Specified QA/Yes release-notes/include webcompat/not-shields-related Sites are breaking because of something other than Shields.

Comments

@sudokai
Copy link

sudokai commented Dec 7, 2018

Test plan

See brave/brave-core#2043

Description

Right clicking on mobile.twitter.com hangs the entire tab for a few seconds.

Steps to Reproduce

  1. Log into twitter.com and go to mobile.twitter.com
  2. Right click on any part of the page, preferably an external link.

Actual result:

Devtools Performance panel screenshot, see the long “Event (context menu)”. Right click menu doesn’t appear until it ends executing all that Javascript, so 11 seconds.

Devtools performance panel screenshot

Expected result:

Right click menu pops up very quickly.

Reproduces how often:

Always.

Brave version (brave://version info)

Brave 0.57.18 Chromium: 71.0.3578.80 (Official Build) (64-bit)
Revision 2ac50e7249fbd55e6f517a28131605c9fb9fe897-refs/branch-heads/3578@{#860}
OS Mac OS X
JavaScript V8 7.1.302.28
Flash (Disabled)
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36
Command Line /Applications/Brave Browser.app/Contents/MacOS/Brave Browser --disable-domain-reliability --disable-chrome-google-url-tracking-client --no-pings --enable-features=EnableEmojiContextMenu,DesktopPWAWindowing,fill-on-account-select,NewExtensionUpdaterService --disable-features=SharedArrayBuffer,DefaultEnableOopRasterization,VizDisplayCompositor,AutofillSaveCardSignInAfterLocalSave,AutofillServerCommunication,UnifiedConsent --flag-switches-begin --flag-switches-end

Reproducible on current release:

  • Does it reproduce on brave-browser dev/beta builds? YES

Website problems only:

  • Does the issue resolve itself when disabling Brave Shields? NO
  • Is the issue reproducible on the latest version of Chrome? NO

Additional Information

@NejcZdovc NejcZdovc added this to the 1.x Backlog milestone Jan 2, 2019
@ostoh
Copy link

ostoh commented Jan 9, 2019

I just experienced this too. The lag took 14.4s.

Brave 0.59.20 Chromium: 72.0.3626.28 (Official Build) beta(64-bit)
Revision 997b1040b63bac324e815797ba52be0cd8f616ed-refs/branch-heads/3626@{#461}
OS Linux
JavaScript V8 7.2.502.13
Flash (Disabled)
User Agent Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.28 Safari/537.36

@sudokai
Copy link
Author

sudokai commented Jan 10, 2019

Well, mobile.twitter.com is now officially the new twitter.com, I just got upgraded to it.

@Brave-Matt
Copy link

@rebron rebron removed this from the 1.x Backlog milestone Feb 7, 2019
@reaktivo
Copy link

I've dug a bit on this issue and found that the cause of the few seconds hang is the unique-selector running while trying to find a unique css selector to block an ad with.

I've opened a pull request for the fix here https://github.com/brave/brave-extension

@nadimkobeissi
Copy link

This also happens on Windows 10.

Brave Version 0.61.51 Chromium: 73.0.3683.75 (Official Build) (64-bit)

@rebron rebron added this to Untriaged Backlog in General Mar 18, 2019
@rebron rebron added webcompat/not-shields-related Sites are breaking because of something other than Shields. priority/P2 A bad problem. We might uplift this to the next planned release. labels Mar 19, 2019
@rebron rebron moved this from Untriaged Backlog to P4 Backlog in General Mar 19, 2019
@rebron rebron moved this from P4 Backlog to P1 & P2 Backlog in General Mar 19, 2019
@bsclifton
Copy link
Member

Quick update - the problem is with our cosmetic filtering code. A unique selector is calculated on right click, in the event that you go into the Brave menu and choose Block element via selector

Looking into a fix now...

bsclifton added a commit to brave/brave-core that referenced this issue Mar 23, 2019
`unique` call (to get selector for target) can be expensive; now only called when user chooses `Block element via selector`

Fixes brave/brave-browser#2410
@bsclifton bsclifton added this to the 0.64.x - Nightly milestone Mar 23, 2019
General automation moved this from P1 & P2 Backlog to Completed Mar 25, 2019
jasonrsadler pushed a commit to brave/brave-core that referenced this issue Mar 25, 2019
`unique` call (to get selector for target) can be expensive; now only called when user chooses `Block element via selector`

Fixes brave/brave-browser#2410
jasonrsadler pushed a commit to brave/brave-core that referenced this issue Mar 25, 2019
`unique` call (to get selector for target) can be expensive; now only called when user chooses `Block element via selector`

Fixes brave/brave-browser#2410
@kjozwiak
Copy link
Member

@brave/legacy_qa once we get a nightly that includes brave/brave-core#2043 & brave/brave-core#2063, we'll need to go through the test plans to ensure that it's working as expected and didn't cause any other obvious performance issues or regressions. We would like to get this uplifted into 0.63.x as well but need to make sure it's working on nightly.

@rebron rebron moved this from Completed to Waiting uplift in General Mar 27, 2019
@bsclifton bsclifton modified the milestones: 0.64.x - Dev, 0.63.x - Beta Apr 3, 2019
@bsclifton bsclifton moved this from Waiting uplift to Completed in General Apr 3, 2019
@GeetaSarvadnya
Copy link

GeetaSarvadnya commented Apr 15, 2019

Verification passed on

Brave 0.63.40 Chromium: 74.0.3729.61 (Official Build) beta (64-bit)
Revision 5df2c8936783bd7575987e45d72a92fcf528496b-refs/branch-heads/3729@{#645}
OS Windows 10 OS Build 17134.523

@kjozwiak
Copy link
Member

kjozwiak commented Apr 15, 2019

Verification PASSED on macOS 10.14.4 x64 using the following build:

Brave 0.63.41 Chromium: 74.0.3729.61 (Official Build) beta(64-bit)
Revision 5df2c8936783bd7575987e45d72a92fcf528496b-refs/branch-heads/3729@{#645}
OS Mac OS X

Verification passed on

Brave 0.63.42 Chromium: 74.0.3729.75 (Official Build) beta(64-bit)
Revision fdb7915642fef8cf997beac2554709d148e3c187-refs/branch-heads/3729@{#754}
OS Ubuntu 18.04 LTS

Used test plan from brave/brave-core#2043 and #2410 (comment)

@Snuupy Snuupy added this to To do in Deprecated Cosmetic Filter via automation May 10, 2019
@Snuupy Snuupy removed this from Completed in General May 10, 2019
@Snuupy Snuupy moved this from To do to Done in Deprecated Cosmetic Filter May 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority/P2 A bad problem. We might uplift this to the next planned release. QA Pass-Linux QA Pass-macOS QA Pass-Win64 QA/Test-Plan-Specified QA/Yes release-notes/include webcompat/not-shields-related Sites are breaking because of something other than Shields.
Projects
No open projects
Deprecated Cosmetic Filter
Work was finished (may need revert)
Development

Successfully merging a pull request may close this issue.