Closed Bug 507963 Opened 16 years ago Closed 16 years ago

Intermittent failure of browser_privatebrowsing_findbar.js

Categories

(Firefox :: Private Browsing, defect)

Product:
Firefox
Component:
Private Browsing
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 3.6a1
Tracking Flags:
Tracking Status
status1.9.1 --- .2-fixed

People

(Reporter: roc, Assigned: mak)

References

(Depends on 1 open bug)

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 1 obsolete file)

patch v1.0
969 bytes, patch
ehsan.akhgari
: review+
Details | Diff | Splinter Review
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249259743.1249266076.16877.gz#err0 This must be intermittent, since the previous test run was green with the same changeset.
Whiteboard: [orange]
Blocks: 438871
Copying Ehsan since he wrote the test, and mconnor since he reviewed it - this is a frequent intermittent orange - is there a real problem here, or just a faulty test?
Attached patch patch v1.0 — — Splinter Review
SynthesizeKey on Linux has focus issues, see bug 495751. if you see above the test failed only on Linux, and i can see why since it uses a bunch of synthesizeKey. Actually putting a window.focus() and focusing the textbox COULD be enough, but no reasons really, value is just working the same way.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Attachment #392827 - Flags: review?(mconnor)
Attachment #392827 - Flags: review?(mconnor) → review?(sdwilsh)
Comment on attachment 392827 [details] [diff] [review] patch v1.0 The window probably doesn't have focus, and making sure it does (by explicitly focusing it) should make sythesizeKey work.
Attachment #392827 - Flags: review?(sdwilsh) → review-
Yes, but still focus on Linux is still bogus, and i really think we should not make browser-chrome tests that depends on focus if we don't really need.
Attached patch patch v2.0 (obsolete) — — Splinter Review
i cannot guarantee this will work as reliably as patch v1.0, i still think that is the right way to go. But if we want to try focus fix first, here it is.
Attachment #392831 - Flags: review?(sdwilsh)
Comment on attachment 392831 [details] [diff] [review] patch v2.0 Yes, I'd prefer to try this first as it's more like what the user would actually do. r=sdwilsh
Attachment #392831 - Flags: review?(sdwilsh) → review+
Actually, reading bug 495751 and bug 497839, it seems that window.focus might sometimes work asynchronously. Given that, and the fact that the synthesizeKey calls in this test are merely an attempt at imitating the real user as much as possible and don't really have any special value to the test at hand, I would prefer the first approach in order to avoid any possible similar problems in the future. Testing that focusing a text box and synthesizing keyboard events to it has the same effect as setting its value property should be a test in the XUL widget code, and it's not too important to worry about it here.
Depends on: 495751
Version: unspecified → Trunk
Comment on attachment 392831 [details] [diff] [review] patch v2.0 Given bug 495751, this is bound to cause further intermittent oranges.
Attachment #392831 - Flags: review+ → review-
Comment on attachment 392827 [details] [diff] [review] patch v1.0 r=ehsan Marco, please proceed to land this when the tree reopens.
Attachment #392827 - Flags: review- → review+
thank you. http://hg.mozilla.org/mozilla-central/rev/a1de621405d2
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1
Thanks for picking this up! This needs to land on 1.9.1 as well.
Whiteboard: [orange] → [orange][needs 1.9.1 landing]
oh. i thought test was not active there. i don't see failures on 1.9.1 above
I suspect that the test failures happen by something done by other tests. I am suspecting the cert exceptions test which opens up dialogs, and hence changes the focus. I'd rather land this now and avoid future oranges than wait till we see oranges on 1.9.1 and then land it there.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249598578.1249606404.18266.gz Linux mozilla-central unit test on 2009/08/06 15:42:58 this failure is not relevat, it is on the push that created the 3.6a1 branch, and it's based on a changeset that is older than the fix for this test.
Attachment #392831 - Attachment is obsolete: true
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b12d1de93e53
status1.9.1: --- → .2-fixed
Whiteboard: [orange][needs 1.9.1 landing] → [orange]
(In reply to comment #24) > paul%oshannessy.com > http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1287089459.1287091577.12715.gz > Rev3 Fedora 12 mozilla-central debug test mochitest-other on 2010/10/14 > 13:50:59 > > s: talos-r3-fed-042 > TEST-UNEXPECTED-FAIL | > chrome://mochitests/content/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_findbar.js > | No items in the undo list of the findbar control - Got 1, expected 0 Ignore this!
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: