1006134 - too much recursion on Linux FF 29

Status: RESOLVED DUPLICATE of bug 1244280

(Core :: JavaScript Engine, defect)

Description

[Brent D.]

User Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140421221237

Steps to reproduce:

Selenium test of FaxLog
xpath=//div[@id="fax-log-grid"]/div/div[contains(@class,"x-panel-body")]/div/table/tbody//*[text()="9807/A001"]/ancestor::tr[1]//a[text()="9807/A001"]

Resulting in
Command execution failure. Please search the forum at http://clearspace.openqa.org for error details from the log window.  The error message is: too much recursion

Tested with FF 29, Linux, works in FF 20


Actual results:

Big red error message


Expected results:

No big red error message

Comment 1

[Boris Zbarsky [:bzbarsky]]

Do you mind checking an Aurora or Beta build, which has bug 960523 fixed?

Comment 2

[Brent D.]

(In reply to Boris Zbarsky [:bz] from comment #1)
> Do you mind checking an Aurora or Beta build, which has bug 960523 fixed?

Hi Boris,

Just tested FF Beta 30 32-bit. Unfortunately the error: 'too much recursion' is still there.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Brent, thanks for checking that.  Do you mind clarifying the steps to reproduce, for someone unfamiliar with Selenium?  If you can put together a step-by-step list of things to do to reproduce the problem, that would help!

Comment 4

[Brent D.]

Hi Boris,

Unfortunately I cannot get into to much detail since it's an 'in-house' application tester. The specific test that FF fails is for a FaxLog.

What I can tell you is it fails the click action for this step:

[FAXLOG.VIEWCRF] Find a fax and view it in the CRF Viewer

// Click on a validated fax and confirm that it opens the CRF Viewer
click 	xpath=//div[@id="fax-log-grid"]/div/div[contains(@class,"x-panel-body")]/div/table/tbody        //*[text()="9807/A001"]/ancestor::tr[1]//a[text()="9807/A001"] 	

Going to the website that the tester is testing is titled:
CRF Tracking System

You are able to view CRFs, look at fax log or statistics, and generate reports

Let me know if there's any additional information I can provide and I'll do my best, but can't guarantee if I can provide for security purposes.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Jan, what would be useful here?

Comment 6

[Jan de Mooij [:jandem]]

(In reply to Boris Zbarsky [:bz] from comment #5)
> Jan, what would be useful here?

Not sure. We could make a build that dumps the JS stack when it throws an over-recursed error but that's not very useful without access to the source code...

I wonder if fun.call/fun.apply are exhausting the stack somehow (like bug 960523), but we can't easily get information about native functions on the stack..

Comment 7

[Brent D.]

(In reply to Jan de Mooij [:jandem] from comment #6)
> (In reply to Boris Zbarsky [:bz] from comment #5)
> > Jan, what would be useful here?
> 
> Not sure. We could make a build that dumps the JS stack when it throws an
> over-recursed error but that's not very useful without access to the source
> code...
> 
> I wonder if fun.call/fun.apply are exhausting the stack somehow (like bug
> 960523), but we can't easily get information about native functions on the
> stack..

Hi Jan,

I'm looking into seeing if I can get ahold of the source code for the specific error I'm coming across. I'll keep you posted.

Comment 8

[Brent D.]

(In reply to Brent D. from comment #7)
> (In reply to Jan de Mooij [:jandem] from comment #6)
> > (In reply to Boris Zbarsky [:bz] from comment #5)
> > > Jan, what would be useful here?
> > 
> > Not sure. We could make a build that dumps the JS stack when it throws an
> > over-recursed error but that's not very useful without access to the source
> > code...
> > 
> > I wonder if fun.call/fun.apply are exhausting the stack somehow (like bug
> > 960523), but we can't easily get information about native functions on the
> > stack..
> 
> Hi Jan,
> 
> I'm looking into seeing if I can get ahold of the source code for the
> specific error I'm coming across. I'll keep you posted.

Unfortunately, the source code cannot be located, however here is the link to selenium which describes the 'click' action: http://release.seleniumhq.org/selenium-core/1.0.1/reference.html#click.

Comment 9

[Brent D.]

Okay, I have some additional information.

Apparently, doing the click action manually does work, however the selenium test does not work.

What happens is I click on a fax, the fax then opens up inside a new tab, and then is displayed inside of CRF viewer.

Here's an explanation from my co-worker who brought the error to my attention:

The part where the test instantly fails (it doesn't hang for me) is just below that.  The source code for my test is:

    // Click on a validated fax and confirm that it opens the CRF Viewer
    click('xpath=${selectRowWithValue("fax-log-grid", MockData.VALIDATED_RASTER_ID)}//a[text()="${MockData.VALIDATED_RASTER_ID}"]')
    waitForPopUp()
    selectWindow('title=CRF Viewer - ${MockData.VALIDATED_RASTER_ID}')

The "click" action is what fails with fails with 'too much recursion'.  Clicking on the same link manually opens the CRF Viewer in a new window.  The link should look something like this:

<a href="/cts/crfViewer/9807%2FA001" target="_blank">9807/A001</a>

Comment 10

[Jan de Mooij [:jandem]]

Brent, I'm very sorry for the delay. Do you still see this with the latest Firefox version?

Comment 11

[Brent D.]

Hi Jan,

Yes, I am still experiencing the same issue with the latest Firefox Version.

Comment 12

[André Bargull [:anba]]

Should be fixed with bug 1244280.