939041 - Browser tab crashes visiting Howler.js web site

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: General, defect)

Description

[znmeb]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131030203622

Steps to reproduce:

1. Built B2G 1.2 preview from source for ZTE Open (inari)
2. Flashed build to ZTE phone
3. Used it for a while
4. Browsed to http://goldfirestudios.com/blog/104/howler.js-Modern-Web-Audio-Javascript-Library



Actual results:

The site loaded find, but in the process of scrolling down, the tab crashed. This appears to be repeatable; every time I go there the tab crashes. 

I have crash reporting turned on on the ZTE Open - the most recent crash report is bp-9f453f52-632b-4add-be9b-84d9f2131115.txt


Expected results:

It should have scrolled down the page.

Comment 1

[Jason Smith [:jsmith]]

Two questions:

1. Does this reproduce on 1.1?
2. Are we able to reproduce this again on the latest 1.3 build? If so, can we get a crash report URL with the latest build available?

Comment 2

[znmeb]

My ZTE is now running 1.3 - specifically B2G 1.3.0.0-prerelease nightly Gecko 28.0a2 ... build is 20140116004002. It's refreshing slowly - it gave me a 'Well, this is embarrassing. We tried to display this Web page but it's not responding' but it doesn't seem to crash any more. I'd *love* to know what sort of JavaScript that page is trying to jam down my 4 Mbit/second connection to the poor processor in the ZTE.

Comment 3

[Jason Smith [:jsmith]]

(In reply to znmeb from comment #2)
> My ZTE is now running 1.3 - specifically B2G 1.3.0.0-prerelease nightly
> Gecko 28.0a2 ... build is 20140116004002. It's refreshing slowly - it gave
> me a 'Well, this is embarrassing. We tried to display this Web page but it's
> not responding' but it doesn't seem to crash any more. I'd *love* to know
> what sort of JavaScript that page is trying to jam down my 4 Mbit/second
> connection to the poor processor in the ZTE.

That implies this bug no longer reproduces then if we aren't generating a crash report anymore. We could consider opening a separate bug to track the the 'well this is embarrassing' problem if you like. But since this bug no longer reproduces, I'm going to close this as a works for me.

Comment 4

[znmeb]

(In reply to Jason Smith [:jsmith] from comment #3)
> (In reply to znmeb from comment #2)
> > My ZTE is now running 1.3 - specifically B2G 1.3.0.0-prerelease nightly
> > Gecko 28.0a2 ... build is 20140116004002. It's refreshing slowly - it gave
> > me a 'Well, this is embarrassing. We tried to display this Web page but it's
> > not responding' but it doesn't seem to crash any more. I'd *love* to know
> > what sort of JavaScript that page is trying to jam down my 4 Mbit/second
> > connection to the poor processor in the ZTE.
> 
> That implies this bug no longer reproduces then if we aren't generating a
> crash report anymore. We could consider opening a separate bug to track the
> the 'well this is embarrassing' problem if you like. But since this bug no
> longer reproduces, I'm going to close this as a works for me.

Howler.js isn't the only site that behaves that way ... rather than a 'bug' perhaps there should be a list of sites like this that the Boot2Gecko / Spidermonkey teams can use as stress tests. Does 1.3 send a report up to the database when a tab dies like this?