Rev3 Fedora 12 x64 permaorange: chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_library_panel_leak.js

RESOLVED FIXED in mozilla1.9.3a5

Status

()

Core
General
RESOLVED FIXED
8 years ago
5 years ago

People

(Reporter: armenzg, Assigned: mak)

Tracking

({intermittent-failure})

unspecified
mozilla1.9.3a5
x86
Linux
intermittent-failure
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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.
(Assignee)

Comment 1

8 years ago
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.
(Assignee)

Updated

8 years ago
OS: Mac OS X → Linux
Blocks: 554934
No longer blocks: 560882
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.
(Assignee)

Comment 3

8 years ago
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.
(Assignee)

Comment 5

8 years ago
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
(Assignee)

Comment 6

8 years ago
I figured out the problem with Ubuntu, I'm proceeding with install and I should be able to test soon.
(Assignee)

Comment 7

8 years ago
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.
Attachment #444369 - Flags: review?
Attachment #444369 - Flags: feedback?(armenzg)
(Assignee)

Updated

8 years ago
Attachment #444369 - Flags: review? → review?(dietrich)
(Assignee)

Comment 8

8 years ago
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?
Attachment #444369 - Flags: review?(dietrich) → review+
(Assignee)

Comment 10

8 years ago
we could try with waitForFocus, but that's still bogus, and it cannot ensure the overlay object is properly initialized still.
(Assignee)

Comment 11

8 years ago
Armen, can you try if this patch solves the issue on Fedora please?
(Reporter)

Comment 12

8 years ago
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
(Assignee)

Comment 13

8 years ago
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.
(Reporter)

Comment 14

8 years ago
(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).
(Assignee)

Updated

8 years ago
Attachment #444369 - Flags: feedback?(armenzg)
(Assignee)

Comment 15

8 years ago
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 :)
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
Comment hidden (Treeherder Robot)
(Assignee)

Comment 17

8 years ago
comment 16 is prior to the fix.

Updated

8 years ago
Blocks: 438871
Keywords: intermittent-failure
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.