Now that we have more greeness we can see more specific oranges. This bug only affects the 64 bit machines. http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_library_panel_leak.js Last 32 bit failure was 2010/04/28 19:12:37 after bug had landed. 2010-04-28 21:12 Firefox Linux [60e85e58fd78] http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1272507157.1272508111.16728.gz Assigning to Marco per request. Let me know if you need access to a Fedora 64 bit machine.
i thought i had posted here. The strange fact is that this happens only on these machines, i could guess some reason for the failure, but all of those would be valid for any platform. Either: we don't have a selection in the Library, we check it too early (some part is lazy initialized) or the Library is messed up due to a previous test.
The full error from the log is: TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_library_panel_leak.js | Editing a bookmark - Didn't expect -1, but got it I see the exact same thing on 64-bit Ubuntu.
hm, then i should probably create a local Ubuntu 64 bit VM box.
I don't think it's because something is messed up due to a previous test, since I see the failure if I run the test alone with no other tests.
Cool, actually i'm fighting with VMWare Workstation 7 that does not want to let me install Ubuntu 10.4 64... Can you check if you see a selected row in Library, I guess opening the library should just work
I figured out the problem with Ubuntu, I'm proceeding with install and I should be able to test soon.
Created attachment 444369 [details] [diff] [review] patch v1.0 This fixes the test on Ubuntu 64 for me, the edit bookmark overlay is initialized when the element in tree has been focused, that happens after the window is opened, thus I guess this system is fast enough to check too early or focus is handled in a more lazy way. Btw, waiting for proper initialization should be fine.
PS: sorry for late but I was unable to build libxul.so, it was churning on disk infinitely, till I tried to bump up VM memory from 512MB to 1GB, and that made the trick :(
Comment on attachment 444369 [details] [diff] [review] patch v1.0 r=me since this is a test. this is still pretty hacky though. is there not a deterministic way for us to listen for this?
we could try with waitForFocus, but that's still bogus, and it cannot ensure the overlay object is properly initialized still.
Armen, can you try if this patch solves the issue on Fedora please?
I will see if I can give it a whirl sometime this week (I just got the windows unit tests handed off). If I get you access to the machine do you think you could give a try? The following link is just for reference to see when was the last time the test fails (once we land it): http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_library_panel_leak.js
Well, I guess I could just land and we check how the boxes reply to that? Accessing to the box from the other side of the ocean does not look much sane with current bandwidth issues.
(In reply to comment #13) > Well, I guess I could just land and we check how the boxes reply to that? > That should work for me. I so wish we had Linux64 try + unit tests (I hope we have it in June).
http://hg.mozilla.org/mozilla-central/rev/7ae8a656ffe9 I'm resolving for now, if we don't see a change we can reopen, but let's be optimist :)
comment 16 is prior to the fix.