search

ChrisNZL / Fauxbar

An alternative to Chrome's Omnibox.
https://chrome.google.com/webstore/detail/fauxbar/hibkhcnpkakjniplpfblaoikiggkopka
MIT License
89 stars 13 forks source link

Fauxbar slowing down page performance with AJAX calls? #33

Closed BigLep closed 6 years ago

BigLep commented 6 years ago

Hello,

For an internal web application, when I click a button, it makes 8 AJAX calls to load various dropdowns. This page action will hang for an extra second or two if Fauxbar is enabled. This is observable with how it takes longer to populate the dropdowns and the whole page comes unresponsive (e.g., loading spinner doesn't spin) When I disable Fauxbar, I don't have an issue. Does this seem plausible to you? Is there any data I can help provide or workarounds you'd suggest? For example, I'm fine not having my history indexed on this page.

Fauxbar 1.7.3 Chrome: Version 63.0.3239.132 (Official Build) (64-bit) OS: macOS 10.12.6

Thanks, Steve

ChrisNZL commented 6 years ago

Sounds related to issue #5.

If you go Fauxbar > Options > Search Engines, and then uncheck "Add search engines to Fauxbar by right-clicking on search fields", does this make things speedy again?

BigLep commented 6 years ago

Hi @ChrisNZL : unfortunately unchecking "Add search engines to Fauxbar by right-clicking on search fields" doesn't improve the performance like disabling Fauxbar. Let me know if there's anything else I should try or provide.

As always, thanks so much for your great support of an amazing product. I feel naked whenever I launch a Chrome instance with Fauxbar.

ChrisNZL commented 6 years ago

Ah dang, hmmm...

Thanks though. Fauxbar is a bit slow on my 2013 MacBook Pro (tab creation being the culprit), but is zippy on my recent Windows laptop. Still not a fan of Chrome's Omnibox after all these years, but still prefer the rest of Chrome. I do go through periods where I'm not interested in fixing minor bugs here, but I seem to come around time and again. Depends on what else is happening with my life.

It sounds weird how your site's Ajax is experiencing slowness with Fauxbar. Any JavaScript errors?

There is one setting, Fauxbar > Options > Address Box > "Use Ajax to detect intranet URLs", but that should only matter when using Fauxbar's Address Box to go to an intranet custom domain, not for regular webpage calls. Maybe try unticking though and see.

And the Address Box option for "Don't show results from:" only applies to searching from Fauxbar's Address Box, not for preventing history items being added to Fauxbar when Chrome adds a history item. I don't currently have anything implemented to prevent user-defined URLs or pages from being added to Fauxbar's database, as I've never experienced SQL insert lag happening for adding, only for doing SQL lookups, which is really only when typing into the Address Box.

Checking Fauxbar's manifest, Fauxbar injects the following scripts into pages:

Bit tricky as your pages are internal so I can't test myself, but I would suggest for you to try:

  1. Clone Fauxbar from GitHub to your computer.
  2. Edit manifest.json and remove the entire "content_scripts" section.
  3. Open chrome://extensions, disable the current Fauxbar, enable the "Developer mode" checkbox, and load your Fauxbar clone - see if it makes a difference.

If removing the "content_scripts" does help, you would then want to re-enable the section, but remove either contextMenu-hoverToggle.js or updatetitle.js (one at a time between tests) - alternatively comment out the contents of both js files one at a time and see which is the culprit (assuming it's even these at all).

BigLep commented 6 years ago

HI @ChrisNZL : thanks for the debugging tips. I can confirm that when I remove updatetitle.js (and updatetitle.js only) from "content_scripts" section, that my performance problems go away.

I don't see any JS errors, but I do see this in the console.

jquery.min.js:16 [Violation] 'readystatechange' handler took 1144ms
jquery.min.js:16 [Violation] 'readystatechange' handler took 1204ms
jquery.min.js:16 [Violation] 'readystatechange' handler took 7902ms

Also, if it's helpful, I can send a performance profile capture when manifesting the issue. It shows the CPU spiking to 100% for 10s.

Thanks again, Steve

ChrisNZL commented 6 years ago

Thanks for investigating. Don't worry about sending a profile.

If I make updatetitle.js defer the chrome.runtime.sendMessage message to only send once every 2 seconds or something when a title changes, rather than on every title change every time, might do the trick.

...Unless the stuff within $(document).ready(function(){ is the slowdown 🤔

Could you please try re-enabling updatetitle.js, but comment out updatetitle.js' chrome.runtime.sendMessage line? This should determine if this line is the culprit - otherwise it'll be something in the $(document).ready stuff causing the issue. (you'll have to click the Reload button on chrome://extensions to apply any changes made to the extension)

Interestingly, searching Google for violation readystatechange handler took, sounds like this is a fairly recent thing with Chrome, being alerted to scripts that are taking too long and blocking other stuff.

BigLep commented 6 years ago

Hi Chris,

I commented out the chrome.runtime.sendMessage but still see slow down. It's only when I comment out the content of "$(document).ready(function(){ " that I get things to be snappy again. Is it maybe something to do with an old version of jQuery? 1.7 was released 11/2011 (per https://github.com/jquery/jquery/releases?after=1.7.1rc1 https://github.com/jquery/jquery/releases?after=1.7.1rc1 ).

Steve

On Jan 6, 2018, at 9:55 PM, Chris McFarland notifications@github.com wrote:

Thanks for investigating. Don't worry about sending a profile.

If I make updatetitle.js https://github.com/ChrisNZL/Fauxbar/blob/master/Fauxbar/js/updatetitle.js defer the chrome.runtime.sendMessage message to only send once every 2 seconds or something when a title changes, rather than on every title change every time, might do the trick.

...Unless the stuff within $(document).ready(function(){ is the slowdown 🤔

Could you please try re-enabling updatetitle.js, but comment out updatetitle.js' chrome.runtime.sendMessage line? This should determine if this line is the culprit - otherwise it'll be something in the $(document).ready stuff causing the issue.

Interestingly, searching Google for volation readystatechange handler took, sounds like this is a fairly recent thing with Chrome, being alerted to scripts that are taking too long and blocking other stuff.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ChrisNZL/Fauxbar/issues/33#issuecomment-355801790, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFNo7TR2UNHRUBdwcf2W9WnKTMb7dPdks5tIFw9gaJpZM4RVRDb.

ChrisNZL commented 6 years ago

Possibly... The jQuery in updatetitle.js is only for the document.ready part though; the rest is regular JavaScript. Would rather not refactor everything jQuery has deprecated over the past 6 years unless absolutely needed.

For me to try:

edit: Could be worth having Chrome inject the latest version of jQuery to other pages. contextMenu-hoverToggle.js is very small to refactor if needed. Old jQuery can still exist for Fauxbar, and latest jQuery can be used for injections.

BigLep commented 6 years ago

HI @ChrisNZL: a couple of things:

  1. Is there anything I can help with?
  2. What does FauxBar due with title changes? Does each title change get added to its search index?
ChrisNZL commented 6 years ago

If you wanted to take a stab at fixing this, go for it.

updatetitle.js' purpose is that, sometimes when Chrome adds a history item, a URL's title can become outdated if the page's title changes via JavaScript later on. Also an issue with the JavaScript/HTML5 technology with the history.pushState() method, page titles would be incorrect in Fauxbar (partly also due to how Chrome doesn't update titles ASAP with this function if I recall correctly (though it's been several years so maybe it's better these days). From memory, easy offender was Facebook, where you'd go to someone's page with their name in the URL, then click on someone else, but Chrome would add the latest person's URL with the previous person's page title, just mismatching like that. So updatetitle.js is meant to listen for title changes to update Fauxbar's database.

From my previous comment, my plan of action would be to:

Bugs and pushing and checking and testing, can take me hours sometimes, right now just isn't good for me. Feel free to try it out in a branch, or if you'd prefer, post the working code for updatetitle.js here and I can merge it in when I get the chance.

ChrisNZL commented 6 years ago

I've created a beta branch: https://github.com/ChrisNZL/Fauxbar/tree/beta Implemented the steps mentioned previously.

Can you please try cloning this this branch and see if it resolves the issue? (if not, any public URL that you can reproduce this issue on would be appreciated)

BigLep commented 6 years ago

Hi Chris,

Sorry I didn't get to trying to implement the changes myself. It was on my hope-to-do list but haven't had a chance yet with some work and family stuff that came up.

I checked out your beta branch and now no longer have the issue. Sorry that I don't have a public URL to share, but it works great from my testing. You're the man - thanks a ton!

Steve

On Jan 14, 2018, at 4:22 PM, Chris McFarland notifications@github.com wrote:

I've created a beta branch: https://github.com/ChrisNZL/Fauxbar/tree/beta https://github.com/ChrisNZL/Fauxbar/tree/beta Implemented the steps mentioned previously.

Can you please try cloning this this branch and see if it resolves the issue? (if not, any public URL that you can reproduce this issue on would be appreciated)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ChrisNZL/Fauxbar/issues/33#issuecomment-357555652, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFNo3M1UvVbZizkqOuT0qLcLFKsJ2jmks5tKpo3gaJpZM4RVRDb.

ChrisNZL commented 6 years ago

Thanks for testing. Yeah, open-source side hobby projects don't get a high priority usually.

Pushed 1.7.4 to Chrome Web Store now, should come live in a hour. Cheers

BigLep commented 6 years ago

Hi Chris,

Just wanted to say thanks again for the great/amazing support. 1.7.4 is working great.

Thanks again, Steve

On Jan 15, 2018, at 11:57 AM, Chris McFarland notifications@github.com wrote:

Closed #33 https://github.com/ChrisNZL/Fauxbar/issues/33.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ChrisNZL/Fauxbar/issues/33#event-1424967501, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFNo3Y3E4s0j72qZy1xWs5sQb_epltmks5tK62vgaJpZM4RVRDb.