196879 - browser buster doesn't complete

Status: RESOLVED WONTFIX

(Webtools Graveyard :: Web Sniffer, defect)

Description

[Judson Valeski]

I'm not sure if this is the right "product" to file this bug under.

The browser buster tests don't fully complete. Some of the sites (www.mp3.com
for one) destroy the top level frame structure (and subsequently the JS context
I presume) that browser buster relies on, and fully load themselves as the top
level document (i.e. www.mp3.com shows up in the URL bar, overriding the buster
URL).

If you hit the back button, then reload buster, the next buster URL load starts
up and life goes on until you hit another site that apparently fully loads
itself as the top level document.

Can browser buster's JS be modified to prevent the top level document from being
loaded over?

Comment 1

[chris hofmann]

I need to get jpatel or benc to periodically scrub the URL list periodically so
the tests run continously...   or figure out some js to ignore _top and ways to
bust out of the frame set.

Comment 2

[Jay Patel [:jay]]

Where can I find the buster.cgi script for this particular version?  I have a
version of buster on my local machine, but it's the one that Waterson had hacked
up (I thinks it's newer than the one hosted on komodo). 

I'm no JS guru, but I can look into possible ways to avoid having the site load
in window.top.  In the mean time, it might just be easier to scrub the list of
any sites that run into this problem as Chofmann suggested.

Comment 3

[benc]

I'm running Choffman's setup as well. 

I had to switch because jay's setup worked, and I blew my Solaris system out of
the water by creating a race condition using the shell scripts. This is user
error, I'm not saying one approach is better than the other, I'm just saying
what the limits are to what I can do.

If we are going to continue to use the shell scripts, then we need to decide a
single home in the cvs tree and do some general cleanup.

Comment 4

[Jay Patel [:jay]]

Well, I hacked up yet another version of browser buster.  I'm currently testing
it out and it seems to be working fine.  

In order to avoid the window.top issue, I simply turned the cgi into a sidebar
tab.  The cgi runs in the sidebar and opens the url in the main window.  This
works great with Netscape 6/7 and Mozilla, but won't really be useful with any
other browser. Sorry! 

Jud:  If this sounds like something that will work for you, I can get it up and
running on a server (maybe even komodo?) next week.  Let me know. Thanks.

Comment 5

[Judson Valeski]

my concern w/ the sidebar approach is that only sidebar enabled clients will be
able to use it. what's nice about the existing buster is that you can point any
device/browser at it and it will churn (modulo this bug :-) ). with that said,
where I run this most often is at home where I have N7 installed.

Comment 6

[chris hofmann]

I've done some thinking about this and think it would be best to set up a
different system for maintaining the url list on browser buster.

doctor is going to make it easier to do self serve fixes when someone spots a
broken url in the list.   To change a url anyone with CVS access to the mozilla
web site can just edit one of the files that contain url entries; like:

http://doctor.mozilla.org/?file=mozilla-org/html/quality/browser/buster/top100/url.25

I'll set up a tracking bug for gathering all the requests for URL changes, cc a
bunch of folks with CVS acccess that can maintain the list, and update the
browser buster home page to point at the tracking bug and tell about the process
for getting broken URLs fixed.

Comment 7

[timeless]

what if browser buster opened its own window to do the busting instead of
relying on a frame? mozilla's default security rules say that only the opener
can close a window, so www.evil.com couldn't close the window, and since browser
buster is now window.opener instead of window.top it should be imune to most
other things.

Comment 8

[Judson Valeski]

sounds reasonable, but still limited to browsers that *can* open multiple
windows (some mozilla embedding devices can't).

Comment 9

[chris hofmann]

there is a tar ball under the mozilla.org content tree under
mozilla-org/html/quality/browser/buster that has all the c-shell scripts and
original URL configuration files.  download that, open it up, and monkey around
with the scripts runtest and rotate_pages if you want to play around and see if
you can hack in a better solution, or add to the solution that we have now.

jpatel's test ought to be an addition since it breaks the original goal of
buster to be able to run continously for any browser that supports just a
minimum of basic html and js. 

we've added several other kinds of tests to http://komodo.mozilla.org/buster to
do different types of stress tests and I think its a good idea to add in new
additions that seem useful.

Comment 10

[lohphat]

FYI, browser buster is not upaating page counter on win32 2003032304 build.

Comment 11

[Erik van der Poel]

One of the first browser buster bugs (bug 14200) was filed under webtools/litmus,
so I'd like this bug to be moved there too.

In any case, it doesn't belong under webtools/websniffer.

Or a new component called buster should be created under webtools.

Or this bug should be moved to limbo, if such a place exists.

Comment 12

[Matthias Versen [:Matti]]

Browser buster is gone