Closed Bug 1268276 Opened 9 years ago Closed 1 year ago

Intermittent browser_usercontextid_tabdrop.js | "" == 1 - JS frame :: browser_usercontextid_tabdrop.js :: <TOP_LEVEL> :: line 80

Categories

(Firefox :: Security, defect, P3)

Product:
Firefox
Component:
Security
Version:
49 Branch
Type:
defect

Tracking

()

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
firefox49 --- affected
firefox57 --- fix-optional

People

(Reporter: KWierso, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 1 obsolete file)

disable test for win and mac
955 bytes, patch
Gijs
: review+
Details | Diff | Splinter Review
Assignee: nobody → allstars.chh
Should we just back this out while we figure out why this is intermittent? It's pretty high up in orangefactor... (ie failing very frequently)
Flags: needinfo?(allstars.chh)
Sorry for causing this problem. I will try to look into this, however I also have other bugs at hand and not sure can fix this in time. If I still cannot fix it this week, I'll file another bug and try to disable that test on win/mac first.
Flags: needinfo?(allstars.chh)
Attached patch Patch. (obsolete) — — Splinter Review
I think the problem is the first test will use http://test1.example.com, and the 2nd test will also use this URL. So the call of BrowserTestUtils.waitForNewTab in the 2nd test return immediately, but actually the result is from the previous one(the 1st test). I change the URL to http://test2.example.com to see it fixes the problem or not. The try on macox64 runs very slowly, I'll keep checking the result. https://treeherder.mozilla.org/#/jobs?repo=try&revision=fce754b03601&selectedJob=20458829
Comment on attachment 8749601 [details] [diff] [review] Patch. Review of attachment 8749601 [details] [diff] [review]: ----------------------------------------------------------------- Hi, Gijs I explained the fix in Comment 5, could you review this for me ? Thanks
Attachment #8749601 - Flags: review?(gijskruitbosch+bugs)
Comment on attachment 8749601 [details] [diff] [review] Patch. (In reply to Yoshi Huang[:allstars.chh] from comment #5) > Created attachment 8749601 [details] [diff] [review] > Patch. > > I think the problem is the first test will use http://test1.example.com, > and the 2nd test will also use this URL. > > So the call of BrowserTestUtils.waitForNewTab in the 2nd test return > immediately, but actually the result is from the previous one(the 1st test). This doesn't make sense - the tab from the first test got closed at the end of the first test, and you call waitForNewTab a second time - there is no way it will "reuse" the TabOpen event from the first tab. The fix here seems to work, judging by the trypush, but we really need to understand *why* before I feel comfortable landing it. If it's just some race condition to do with when pages are cached etc. it'll keep happening even after this fix, just less frequently.
Attachment #8749601 - Flags: review?(gijskruitbosch+bugs)
Attached patch disable test for win and mac — — Splinter Review
Hi Gijs I think I still need some time to check this, so I'd like to disable it on mac and win first. Thanks for the review.
Attachment #8750255 - Flags: review?(gijskruitbosch+bugs)
Attachment #8750255 - Flags: review?(gijskruitbosch+bugs) → review+
Keywords: leave-open
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Assignee: allstars.chh → nobody
Status: ASSIGNED → NEW
Severity: normal → S3

The last failure was reported 5 years ago. Closing this bug.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: