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

UI becomes unresponsive when rapidly creating tabs via CTRL + T #10749

Closed
kjozwiak opened this issue Aug 31, 2017 · 9 comments
Closed

UI becomes unresponsive when rapidly creating tabs via CTRL + T #10749

kjozwiak opened this issue Aug 31, 2017 · 9 comments
Assignees
Labels
bug feature/newtab fixed-with-brave-core This issue will automatically resolved with the replacement of Muon with Brave Core. priority/P4 Minor loss of function. Workaround usually present. release-notes/include wontfix

Comments

@kjozwiak
Copy link
Member

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

Yes

- Describe the issue you encountered:

When rapidly opening a bunch of tabs via "CTRL + T", the Brave UI becomes completely unresponsive after opening 6-15 tabs.

- Platform (Win7, 8, 10? macOS? Linux distro?):

Win 10 x64 - Reproduced
macOS 10.12.6 x64 - Reproduced

- Brave Version (revision SHA):

Brave 0.18.24 rev | 1853c35
Muon 4.3.14
libchromiumcontent 60.0.3112.101

- Steps to reproduce:

  1. Open Brave 0.18.24 rev | 1853c35
  2. Rapidly opened a bunch of tabs using CTRL + T

- Actual result:

The entire Brave UI becomes unresponsive

- Expected result:

The Brave UI shouldn't become unresponsive when rapidly opening tabs via CTRL + T

- Will the steps above reproduce in a fresh profile? If not what other info can be added?

Yes

- Is this an issue in the currently released version?

No

- Can this issue be consistently reproduced?

Yes, using the above STR, the issue is 100% reproducible

- Screenshot if needed:

unresponsiveissue

rapidtabs

@bbondy bbondy closed this as completed in 1e2c5eb Aug 31, 2017
bbondy added a commit that referenced this issue Aug 31, 2017
Fix #10749

I don't think I can add a test for this since it's so unfrequent but it will go away once we get rid of frame state
bbondy added a commit that referenced this issue Aug 31, 2017
Fix #10749

I don't think I can add a test for this since it's so unfrequent but it will go away once we get rid of frame state
bbondy added a commit that referenced this issue Aug 31, 2017
Fix #10749

I don't think I can add a test for this since it's so unfrequent but it will go away once we get rid of frame state
@srirambv
Copy link
Collaborator

srirambv commented Sep 4, 2017

App is quite slow when opening a lot of tabs on Windows. CPU usage spikes a lot while loading pages on all tabs.

#5419

@luixxiul
Copy link
Contributor

luixxiul commented Sep 7, 2017

@kjozwiak what is the issue not fixed here?

@cndouglas
Copy link

+1 from me (#10866)

@bbondy
Copy link
Member

bbondy commented Sep 11, 2017

@kjozwiak is this the same as #10866 or no? I can't reproduce this one but I can reproduce #10866.

@bbondy bbondy added this to the 0.20.x (Developer Channel) milestone Sep 11, 2017
@bbondy bbondy removed this from the 0.19.x (Beta Channel) milestone Sep 11, 2017
@bbondy
Copy link
Member

bbondy commented Sep 11, 2017

Seems different from #10866 (who's fix is to queue events until window is ready). This fix is after window is ready so won't be fixed by a fix like that. Moving this one since @kjozwiak says it's rare to 0.20.x for re-assessment later.

@bsclifton
Copy link
Member

bsclifton commented Sep 16, 2017

From the screenshot by @kjozwiak, this is where it's crashing at (state is null/undefined):

if (openInForeground == null || state.get('activeFrameKey') == null) {

This is fired when processing the APP_NEW_WEB_CONTENTS_ADDED action. It seems one of the reducers is returning null or undefined

@ghost ghost added the priority/P3 Major loss of function. label Sep 26, 2017
@ghost ghost assigned kjozwiak Sep 26, 2017
bbondy added a commit that referenced this issue Oct 6, 2017
@alexwykoff alexwykoff removed this from the 0.20.x (Beta Channel) milestone Oct 24, 2017
@alexwykoff alexwykoff added priority/P4 Minor loss of function. Workaround usually present. and removed priority/P3 Major loss of function. release/blocking labels Oct 24, 2017
@kevinp2
Copy link

kevinp2 commented Nov 3, 2017

@kjozwiak , what software did you use to record the video / image / animation of the Brave tabs above?

@kjozwiak
Copy link
Member Author

kjozwiak commented Nov 3, 2017

@kjozwiak , what software did you use to record the video / image / animation of the Brave tabs above?

@kevinp2 using a tool called Licecap [1] which captures an area of your desktop and turns it into a .gif file. Really useful tool!

@bsclifton bsclifton added this to the Backlog (Prioritized) milestone Nov 22, 2017
@bsclifton bsclifton modified the milestones: Backlog (Prioritized), Triage Backlog Sep 18, 2018
@bsclifton bsclifton removed this from the Triage Backlog milestone Sep 18, 2018
@kjozwiak
Copy link
Member Author

We're finally going to get rid of this with brave-core 🎉 One of the first issues that I QA'd when I started here which led to this bug + a bunch more!

@bsclifton bsclifton added the fixed-with-brave-core This issue will automatically resolved with the replacement of Muon with Brave Core. label Sep 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug feature/newtab fixed-with-brave-core This issue will automatically resolved with the replacement of Muon with Brave Core. priority/P4 Minor loss of function. Workaround usually present. release-notes/include wontfix
Projects
None yet
Development

No branches or pull requests

9 participants