519504 - [faceted search]: wrong encoding in the timeline

Status: NEW

(Thunderbird :: Search, defect)

Description

[Valery Kondakoff]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.4pre) Gecko/20090929 Shredder/3.0pre

From time to time there is a wrong encoding in the faceted search timeline. Here are two screenshots to illustrate the problem:

1) Wrong encoding after search 'test': http://www.rugby-forum.ru/temp/gloda.jpg
2) Right encoding after the same search: http://www.rugby-forum.ru/temp/gloda1.jpg

Reproducible: Always

Comment 1

[Mark Banner (:standard8)]

(In reply to comment #0)
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
> rv:1.9.1.4pre) Gecko/20090929 Shredder/3.0pre

Quite clearly this is not what you are actually using or if you are it is set up wrong as it is reporting that you are using the English version.

Are you actually using the ru version?

Comment 2

[Valery Kondakoff]

Why do you think so? It _is_ an English version: http://www.rugby-forum.ru/temp/gloda2.jpg .

Comment 3

[Simon Paquet [:sipaq]]

Mark, I don't know the faceted search code, but maybe it takes the month names directly from the underlying operating system?

Comment 4

[David Ascher (:davida)]

correct, it just does .toLocaleFormat(...)

I'm confused about the issue, though cause that XHTML page (glodaFacetView.xhtml) uses UTF-8 as an encoding.  The "from time to time" bit, therefore, totally baffles.

Valery -- if you can get reliable steps to reproduce, that'd be great.

Comment 5

[Valery Kondakoff]

I'm receiving:

 Warning: Cannot specify value for internal property.  Error in parsing value for '-x-system-font'.  Declaration dropped.
Source File: chrome://messenger/content/glodaFacetView.xhtml
Line: 0

on every displaying of the search results. Can this be related to the encoding problem?

Comment 6

[Valery Kondakoff]

There are several (2-3) 'Cannot specify value for internal property' warnings when i click on a month name in the time line. And there are 11 warnings when I click on an magnifier glass to bring all the months back.

There is 'Error: facet.newest is null
Source File: chrome://messenger/content/glodaFacetVis.js
Line: 110' when I click on an 'empty' month (a month without messages).

Comment 7

[David Ascher (:davida)]

Comment #5: that's unrelated.

Comment #6, first part: also unrelated I think.

Comment #6, second part: unrelated as well (and filed somewhere, but can't find it)

Comment 8

[Valery Kondakoff]

(In reply to comment #7)

> Comment #6, first part: also unrelated I think.

At least, when there is a search result with the wrong encoded month names it is enough to switch 'one month'/'multiple months' view two-three times to bring the correct encoding back...

Comment 9

[Valery Kondakoff]

After some experimenting I still think the timeline encoding problem is somehow related to wrong initialization of the font, used in the timeline.

When I'm using a search term (ttestt, for example) which is not available in my messagebase, the search results page does not fire the 'Error in parsing value for '-x-system-font' warning. This is because no timeline is visible in an emty search results page.

When I'm using a search (ttest, in my example) which fires a search results page with timeline containing only the years (not months) - I'm receiving one 'Error in parsing value for '-x-system-font' warning for each of the years available in the timeline.

When there are months in the timeline there is much more 'Error in parsing value for '-x-system-font' warnings. It seems month value can fire more than one warning at the initialization time.

Comment 11

[Valery Kondakoff]

still unconfirmed? :)

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

Given that the problem is intermittent I'm going to assert that this is bug 547088 and that the thing that varies is whether or not we end up populating the visualization on a setTimeout or an XPConnect callback.

I am going to confirm based on that bug being real; much thanks for Jonathan Protzenko bringing this situation to my problems.

The workaround is for us to make sure we build the JS visualization in a DOM JS context, setTimeout being the canonical guarantor of such things.  The workaround is easy but effectively untestable from an automation perspective at this time.

Requesting 3.1 blocking for guidance on whether it's acceptable to cherry-pick this very low hanging fruit with a speculative fix sans testing.

Comment 13

[OOO until Apr 20; Dan Mosedale (:dmosedale, :dmose)]

This wouldn't block, but a speculative fix sounds fine.  Whether it's acceptable for the patch to land without a test is a call that needs to be made by the reviewer once there's a patch in-hand, based on the usual cost/benefit analysis.