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

NoScript interaction: jerky, staggered rendering of pages #75

Open
jsamuel opened this issue Dec 22, 2011 · 10 comments
Open

NoScript interaction: jerky, staggered rendering of pages #75

jsamuel opened this issue Dec 22, 2011 · 10 comments

Comments

@jsamuel
Copy link
Member

jsamuel commented Dec 22, 2011

imported trac ticket
created: 2010-01-30 17:19:07
reporter: al_9x

first posted to the NoScript forum:
http://forums.informaction.com/viewtopic.php?f=10&t=3730

xp32sp3, Fx 3.6.0, NS 1.9.9.42, RP 0.5.12, new profile

I've noticed what seems to be a slower, staggered, jerky, loading of some pages (including NoScript forum), where a partially rendered, not fully themed page is first displayed and then refreshed. Here is a screencap video: http://rapidshare.com/files/343278054/ns-rp.wmv.html (playable with WMP, SMPlayer)

I've narrowed it down to a combination of NS and RP, disabling either makes the page load quicker, in an non staggered, non jerky manner.

To repro:

  1. start with a new profile with NS and RP
  2. go to http://www.phpbb.com/
  3. do a Shift+Reload (Ctrl+F5) several times, and you will see the described effect
  4. disabling NS or RP or both makes the page load normally

Giorgio (NoScript author) and another person form the NoScript forum, say that RP alone causes the problem.

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2010-01-31 21:27:21
author: justin

Thanks for reporting this. I also can see this happening in some cases but I haven't fully tracked it down. I do 100% believe that RP increases the likelihood of this happening. I think it's a safe bet that even if NS also can contribute to the likelihood of this, most of the blame probably lies with RP. I'm inclined to think this primarily because NS has something like 3 orders of magnitude more users than RP, so if NS was the primary culprit than it probably would be a well known issue. Also, I've done my best to keep algorithmic and data structure stuff reasonably fast, but I haven't gone back and done much work on code optimization and identifying hot spots.

I'll keep looking into this. I have identified some ways that seem to help, but I have yet to completely address the issue. I can't be sure I'll be able to totally fix it for all users, but I'll try to keep digging over the next few weeks and at least try to improve it.

As for why you only see this with both enabled: my guess is that maybe the delay in download decisions as well as other processing load caused by either extension on its own isn't enough to cause Firefox to exhibit the behavior, but both together pushes your setup over the edge. This doesn't mean RP and NS are equal contributors. For example, maybe it's 9/10 RP but you don't see it without the extra 1/10 contributed by NS.

It also seems possible from what I've seen so far that unoptimized websites can contribute to this issue being noticed. That doesn't mean RP shouldn't address it, but certain slow aspects of some websites may help trigger what you're seeing.

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2010-02-02 22:27:22
author: justin

I believe this is fixed by r316. Assuming these changes haven't broken anything, they will be included in the next release.

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2010-02-02 23:15:46
author: justin

So, I think this is a bit better, but it's definitely not completely solved. In my testing of these changes, I was able to find some cases where with the changes the problem was no longer happening. However, I have found others where it still happens.

Here's a beta that includes the changes of r316:

https://www.requestpolicy.com/releases/requestpolicy-0.5.14b1.xpi

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2010-02-02 23:24:41
author: justin

For reference, here's a site that I can very reliably repeat the problem on:

http://news.bbc.co.uk/

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2010-02-02 23:54:16
author: justin

I take it back. Even http://news.bbc.co.uk/ works fine with a fresh profile and only RP 0.5.14b1 installed. A clean profile with NS 1.9.9.42 installed, however, gives me the no-stylesheet-flicker about half of the time when I reload without cache.

I still am pretty certain that a slow enough system could still have this happen with RP, but my impression is that it's pretty good now and I don't have any example where RP on its own causes problem, nor RP with NS where NS alone doesn't cause the problem.

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2010-02-03 09:05:03
author: al_9x

It is not fixed for me. Here is a capture of shift+reloading http://www.phpbb.com/ in a new Fx 3.6.0 profile with RP 0.5.14b1 and NS 1.9.9.42. Happens every time. Ok with RP alone.
http://rapidshare.com/files/345392143/ns-rp14.wmv.html

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2010-02-03 09:12:22
author: al_9x

correct link: http://rapidshare.com/files/345397334/ns-rp14.wmv.html

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2010-02-03 22:17:25
author: justin

As I can't repeat the problem anymore, it's going to be difficult to make more progress on it at the moment. I'm going to leave the ticket open, but I'm removing it from 0.5.14. --- Note that I do think a big improvement was made with r316, it just isn't big enough in some cases.

And thanks for the video. This was the same thing I was seeing and that I think has been improved. My guess is that it's still an issue of probably the speed of the computer as well as the speed of server and network connection. I also haven't tested this specific issue on many different platforms and different versions of Fx, so maybe that has something to do with it. (I'm using 3.6.1pre on Linux at the moment and only doing basic testing on other versions and platforms.)

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2011-03-24 05:18:12
author: vivaelamor

I have this problem on http://www.phpbb.com and have found that disabling the option 'indicate blocked images' fixes it, at least on that site. I am running Firefox 4.0 on Linux, with NoScript.

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2011-09-05 11:01:32
author: justin

vivaelamor is right. The current implementation of "indicate blocked images" is at least one culprit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant