561321 - Quick filter bar buttons Starred, Contact, and Attachments don't work in 3.2pre builds

Status: RESOLVED WORKSFORME

(Thunderbird :: Search, defect)

Description

[Steffen Wilberg]

On trunk (Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100422 Lightning/1.1a1pre Shredder/3.2a1pre), the quick filter bar buttons Starred, Contact, and Attachments don't work.
Only Unread and Tags work as expected.

Error Console doesn't display anything related.

Lanikai (3.1pre) works fine.

Comment 1

[Ludovic Hirlimann [:Usul]]

This is a bug in the JS engine. You shouldn't be using 3.2 builds atm.

Comment 2

[Steffen Wilberg]

Is that JS engine bug filed somewhere?

Bug 559299 led me to using 3.2 builds. I can take a bit of breakage, filing bugs as I go, as long as they don't actually shredder mails stored on my imap accounts. Is there anything serious I need to aware of, or just the fact that they're not tested as much?

Comment 3

[Alfred Kayser]

3.2 builds are not for production, but for testing.
So, reporting bugs in something that doesn't work in 3.2 versions is the The Right Thing to do. Trusting 3.2 nightly builds is not so, things may fail (that is why 3.2 nightly builds are there, to see if things fail, they shouldn't but...).
Aside from all this, I continuously use the 3.2 nightlies, as it is still much better than the current official release, with all the nice new features.
(And when it fails, I am less frustrated, because it is a nightly...)

Comment 4

[Steffen Wilberg]

I can't remember using a release build...
The question is if 3.2pre nightlies are seriously more broken than 3.1pre nightlies, and it doesn't look like it. Bug 559299 and this bug are the only differences I noticed so far.

Comment 5

[Wayne Mery (:wsmwk)]

[OT] anyone feel that 3.2 is faster than 3.1 as stated by C@rb0n in http://forums.mozillazine.org/viewtopic.php?f=29&t=1862545

(In reply to comment #2)
> Is there anything serious I need to aware of, or just the fact that
> they're not tested as much?

also, there are way more 3.1 testers than 3.2. And the normal, branch breakage (in this case 3.1) typically get higher priority than trunk breakage (in this case 3.2)

Comment 6

[Mark Banner (:standard8)]

(In reply to comment #3)
> Aside from all this, I continuously use the 3.2 nightlies, as it is still much
> better than the current official release, with all the nice new features.
> (And when it fails, I am less frustrated, because it is a nightly...)

That statement is wrong - up until feature freeze the only difference between 3.1 and 3.2 is the core gecko, and that difference doesn't actually give any features to TB's UI between 3.1 and 3.2.

However, this is all getting OT for this bug.

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to comment #1)
> This is a bug in the JS engine.

is there a bug# or reference?

Comment 8

[Nomis101]

If I use a 3.2 debug build (Mac OS X), than I get the following while using the new quicksearch (maybe this can help to identify the JS bug):


WARNING: leaking reference to nsTimerImpl: file /Volumes/Developer/temp/src/mozilla/xpcom/threads/nsTimerImpl.cpp, line 493
--DOMWINDOW == 16 (0x2f193fa0) [serial = 11] [outer = 0x2e9f8040] [url = about:blank]
WARNING: NS_ENSURE_TRUE(thread) failed: file /Volumes/Developer/temp/src/mozilla/netwerk/base/src/nsSocketTransportService2.cpp, line 121
-- Exception object --
+ message (string) 'domNode is not defined'
+ fileName (string) 'chrome://messenger/content/quickFilterBar.js'
+ lineNumber (number) 194
+ stack (string) '([object XULCommandEvent])@chrome://messenger/content/quickFilterBar.js:194
'
+ name (string) 'ReferenceError'
*
-- Stack Trace --
([object XULCommandEvent])@chrome://messenger/content/quickFilterBar.js:194
-- Exception object --
+ message (string) 'domNode is not defined'
+ fileName (string) 'chrome://messenger/content/quickFilterBar.js'
+ lineNumber (number) 194
+ stack (string) '([object XULCommandEvent])@chrome://messenger/content/quickFilterBar.js:194
'
+ name (string) 'ReferenceError'
*
-- Stack Trace --
([object XULCommandEvent])@chrome://messenger/content/quickFilterBar.js:194
-- Exception object --
+ message (string) 'domNode is not defined'
+ fileName (string) 'chrome://messenger/content/quickFilterBar.js'
+ lineNumber (number) 194
+ stack (string) '([object XULCommandEvent])@chrome://messenger/content/quickFilterBar.js:194
'
+ name (string) 'ReferenceError'
*
-- Stack Trace --
([object XULCommandEvent])@chrome://messenger/content/quickFilterBar.js:194
-- Exception object --
+ message (string) 'domNode is not defined'
+ fileName (string) 'chrome://messenger/content/quickFilterBar.js'
+ lineNumber (number) 194
+ stack (string) '([object XULCommandEvent])@chrome://messenger/content/quickFilterBar.js:194
'
+ name (string) 'ReferenceError'
*
-- Stack Trace --
([object XULCommandEvent])@chrome://messenger/content/quickFilterBar.js:194
WARNING: NS_ENSURE_TRUE(thread) failed: file /Volumes/Developer/temp/src/mozilla/netwerk/base/src/nsSocketTransportService2.cpp, line 121

Comment 9

[Mark Banner (:standard8)]

This bug is also causing the mozmill failures on trunk.

A possible workaround seems to be setting javascript.options.jit.chrome to false.

Comment 10

[Mark Banner (:standard8)]

Something in the latest tracemonkey merge fixed this - we've now backed out the disabling and this is all working fine.