Closed Bug 923071 Opened 7 years ago Closed 6 years ago

Test failure "Scroll arrows are visible after a couple tabs have been opened" in testTabbedBrowsing/testBackgroundTabScrolling.js

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect, P4)

x86_64
All
defect

Tracking

(firefox26 unaffected, firefox27 affected, firefox30 affected, firefox-esr24 affected)

RESOLVED WORKSFORME
Tracking Status
firefox26 --- unaffected
firefox27 --- affected
firefox30 --- affected
firefox-esr24 --- affected

People

(Reporter: mario.garbi, Unassigned)

References

()

Details

(Whiteboard: [mozmill-test-failure])

Happened today on Mac 10.6.8 with Nightly 27.0a1 en-US using Mozmill 2.0:

http://mozmill-daily.blargon7.com/#/functional/report/6ec6776efe900da3fd2b64a750c3bca0
Priority: -- → P3
While trying to reproduce this I noticed a large number of crashes caused by bug 923290. There is an inbound build where this has been fixed so we should keep an eye for future failures like this and close it if they stop.
Depends on: 923290
Assignee: nobody → mario.garbi
Status: NEW → ASSIGNED
Anything else we have to do here? Was the crash the only issue? I don't think so, right?
I tried to reproduce this bug but I was only able to reproduce the crash in bug 923290.

The failure here happens if it takes too long to open the necessary number of tabs needed to show the scroll arrow. This can happen if the machine is being slowed down by a large number of error dialogues.
When I first logged on the machine there were about 7 error report dialogues.

I will continue the investigation and look for other possible causes.
I investigated the issue here in detail and managed to reproduce it locally by changing the timeout to 1000ms. Using date.getTime() I noticed that it takes us around 1300 ms to open the necessary number of tabs with slights oscillations but never more than 1.3 seconds.

The problem here could have been cause by the crashes previously specified if mozmill didn't realized that Firefox crashed and still waited for the element to show. I will keep investigating this and try to reproduce it with mozmill 2.0.
Mario, any update on this bug? It's behind more than a month. Have we seen the failure again?
Flags: needinfo?(mario.garbi)
We haven't seen this since 04.10.2013 and as I said in comment 4 it might have been caused by the issues we had at that time. I cannot reproduce it locally without manually decreasing the timeout. I think it's safe to close as WFM.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(mario.garbi)
Resolution: --- → WORKSFORME
OS: Mac OS X → All
Failed today again on Firefox 24.6.0esrpre en-US on mm-osx-107-2 (20140618000506)
4 failures this month, all on ESR anc an Mac OSX.

http://mozmill-daily.blargon7.com/#/functional/report/6959f9a8236961096763389083dca888
Duplicate of this bug: 1023206
This failed again.
ESR24 http://mozmill-daily.blargon7.com/#/functional/report/6959f9a8236961096763389083dca888

Well, all failures we've seen are on ESR24.
There are a total of 3 instances from a year ago which are on 30 and 27, and one instance form 2014-02 which is again on 30.

I'm going to mark this one as WFM.

Please reopen if this happens on any active branch. (Not ESR24 or 30)
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → WORKSFORME
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.