423955 - list content popups shows in left up corner of mail windows

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Igor Velkov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9b5pre) Gecko/2008031902 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9b5pre) Gecko/2008031902 SeaMonkey/2.0a1pre

Always when I start seamonkey mail window opens with list over left upper corner of window. Content of overlay looks like content drop-down list box from quick view filter, view->tags, and ower it content of drop-down list box from quick view filter, view->custom filters.

On the screenshot can view that this lists have different width: top part oerlays to full folder pane width, but a little lover mesage counts can be viewed: there is tg list, and it have smaller width.

This pane not react to mouse clicks.

If I close mail window and open, as usual, all works ok. It can be again next window open, or may be not.

This effect occurs about 50% of opens mail and news window.

Reproducible: Sometimes

Comment 1

[Igor Velkov]

Attachment: screenshot

Comment 2

[Karsten Düsterloh]

Okay, standard questions:
- Do you have any extensions installed?
- Does it happen with a clean profile?
- Does it happen when you start SM in safe mode (command-line parameter -safe-mode)?

Comment 3

[Igor Velkov]

Yes, I have a lot of extensions installed.
It not occured in safe mode in 15 minutes, but I will continue tryes some days.

Comment 4

[Igor Velkov]

This effect appear only if Greasemonkey extension is enabled.

Comment 5

[Kent James (:rkent)]

I am seeing this as well on Thunderbird trunk based on a 2008-03-27 CVS download.

I create a new profile. Then I add the "Views" toolbar button (problem occurs immediately).

If I restart mailnews, I can make the issue appear by selecting views, and moving my mouse over the Tags item. I'm also running Windows XP.

Comment 6

[Igor Velkov]

When I repot this bug, it occur every time on firs open of mail window, and on some opens after, but not the every.
After fix of bug 428257 (?) this effect seems every time, if I hover mouse pointer over tag and view list from pull-down menu of "view" box in mail toolbar.
If I disable xSidebar or Greasemonkey extension - this effect newer occures

This efect start after update to Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9pre) Gecko/2008041102 SeaMonkey/2.0a1pre ID:2008041102
with previous build initial bug description was actual.

Comment 7

[Igor Velkov]

sorry, I miss: there was no check-in for bug 428257.

Comment 8

[Kent James (:rkent)]

I also see a similar bug in a different location (using Thunderbird 2008-04-09 custom build, Windows XP):

Open Tools/Message Filters. In the Filters For dropdown box, select another account.

In the upper left hand corner of the Message Filter dialog, I see a label which says "choose this folder" that overwrites the dropdown box.

This same build does not show the same symptoms in my Windows 2000 VMware development system. It may be Windows XP specific. It looks like a rendering bug.

Comment 9

[Kent James (:rkent)]

Problem is seen in downloaded Thunderbird trunk builds dated 2008-01-08, not seen in 2007-06-01. Let me binary search to find the date of the regression.

Comment 10

[Kent James (:rkent)]

Problem does not occur in Thunderbird build 2007-07-04-05-trunk
Problem does occur in Thunderbird build 2007-07-05-05-trunk

Likely cause: bug 279703  I'm cc'ing [e-mail] the author of that bug for comment. Also, changing summary to reflect both Igor's case and mine.

Comment 11

[Frank Wein [:mcsmurf]]

Confirming this bug based on comments and I also saw this bug here.

Comment 12

[Wayne Mery (:wsmwk)]

I don't see any of the problems described when using vista version 3.0a1pre (2008041203)

Comment 13

[Kent James (:rkent)]

I cannot confirm this on a fresh install of Windows XP on Vmware, and using TB version 3.0a1pre (2008010204)  So I am beginning to suspect it may be limited to a particular video driver.

My system that shows the problem is a Fujitsu Stylistic ST5030 Tablet. The display adapter is a Mobile Intel(R) 915GM/GMS.910GML Express Chipset Family

Comment 14

[Igor Velkov]

I see it on Nvidia GeForce 6800 GS, nv dlls 6.14.11.6921

Comment 15

[Kent James (:rkent)]

To update my comment 13, I do see this problem on my development machine as well as my user machine. The development environment is Windows 2000 in a VMware virtual machine on an Amd X2 processor.

Wayne, this is a quite annoying bug because you have to shutdown Thunderbird to get rid of the junk on the screen. When present, it always occurs when using certain dropdown menus. My fear is that it is more widespread among Windows Mailnews users than is appreciated. Could you try to add this to the bugday tests to see if you can get a better idea of how widespread this is among Windows users?

It might also be appropriate to file a Thunderbird or Mailnews-specific bug for this to give it some visibility.

Comment 16

[Wayne Mery (:wsmwk)]

and your user machine is the tablet?

This really isn't actionable via bug day. I doubt it's widespread if your regression range is accurate because there'd have been far more reports many months ago. iirc there are many XUL problems on trunk so these might be worth scanning. And, if you all are certain of the regression range then it would be good to set this bug as blocking the cause.  

sev=major

Comment 17

[Igor Velkov]

It is strange, but I not see it about a week (I install fresh nightlies every morning, with rare exclusions).
Second, I want to remember, I not use thunderbird, but seamonkey. 
Maybe, this bug was fixed in seamonkey, but present in thunderbird? Or it is impossible?

Comment 18

[Igor Velkov]

Not see this effect around 2 weeks. 

Comment 19

[Igor Velkov]

Not seen more a month.
Can be closed.

Comment 20

[Kent James (:rkent)]

I just installed a 2008-05-28 Thunderbird trunk nightly, and I still see the behavior of this bug on my Fujitsu tablet.

Comment 21

[Kent James (:rkent)]

This bug was quite reliable for me - until today I uninstalled my Logitech webcam that was also preventing MSYS and CYGWIN from working. Now it's gone (the bug and the camera)! I guess I need to reinstall the webcam to confirm that the problem returns.

However, I did also see it a few months ago on a Windows 2000 VM that did not have this webcam, though I can no longer reproduce that.

Comment 23

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

This happens consistently and reliably for me on linux on trunk builds.

Comment 24

[Kent James (:rkent)]

I've removed everything Logitech from my system and I am still seeing this
completely reproducibly. With at least three of us seeing it on TB3, perhaps it
is a more widespread issue. I've been assumming that the distribution was
fairly limited, based on the quiet that has reigned here for the last 8 months.
But if more widespread, this is a serious problem.

So I'm going to start a dupe war with myself, undup bug 488381 (which is a TB
bug) so that I can set TB driver flags on it, and request blocking for TB3.
Maybe that can get XUL expert attention directed toward this. (I cringe in
horror at the prospect that asuth or I would have to learn enough XUL backend
to investigate this!)

Comment 25

[Mark Banner (:standard8)]

So I guess we need a bit more information on this bug.

Do we dynamically build the menu each time we display it, or do we have some form rebuild/update only when the tag list changes?

Comment 26

[Dan Mosedale (:dmosedale, :dmose)]

Neil, can you comment on how likely you think this is to be a regression from bug 279703?

Comment 27

[Neil Deakin]

Looks like the view for the popup is being displayed without it being open. Someone with a debugger and can reproduce it (I can't reproduce it) could look at nsContainerFrame::SyncFrameViewProperties (or nsIViewManager::SetViewVisibility) and look to see where and why the view is being made visible.

I assume that the menu here is a normal menulist?

Comment 28

[Kent James (:rkent)]

The false display is occurring from a menupopup that is the child of a menu (that in turn is a child of a menupopup, is a child of a menulist. So for example the item with id="viewPickerCustomViewsPopup" shows the problem, in a tree of item(id) as follows:

menulist(viewPicker)/menupopup(viewPickerPopup)/menu(viewPickerCustomViews)/menupopup(viewPickerCustomViewsPopup)

which is located here:

http://mxr.mozilla.org/comm-central/source/mail/base/content/extraCustomizeItems.xul#161

As for examining with a debugger, the problem is (see bug 488381 comment 10) that the problem only shows in release builds, not in debug builds, at least for me (Windows XP) and asuth (Linux). So I am afraid that this is going to have to be debugged with compiled-in printf statements unless you have a better idea.

Since I am seeing this quite reliably and have that capability, I would be happy to try to do some of that tedious work, if you could at least point me in the correct direction to show where in the layout code I could get a handle on what is happening.

As for "Looks like the view for the popup is being displayed without it being open" that is not how I would characterize this. The most common occurance is that the popup is displayed twice, once in the correct position and once in the corner.

Looking briefly at nsContainerFrame::SyncFrameViewProperties, the comment "See if the frame is being relatively positioned or absolutely" makes me say that the problem could be described as that the popup is displayed twice, once (falsely) mistaking relative for absolute coordinates, and then correctly.

Comment 29

[Neil Deakin]

> Looking briefly at nsContainerFrame::SyncFrameViewProperties, the comment "See
> if the frame is being relatively positioned or absolutely" makes me say that
> the problem could be described as that the popup is displayed twice, once
> (falsely) mistaking relative for absolute coordinates, and then correctly.

No it's not that as popups aren't positioned elements. I was referring to the call to SetViewVisibility which, among a number of callers, might make the popup visible incorrectly.

But you say that this causes two versions of the popup to display, which suggests it might not be that. Are we sure that there is only one popup being painted in two places, or two different popups. dom inspector would let us see this perhaps. Or, adding capturing popupshowing/popupshown events to the window would let us see is multiple popups were opening.

If there is only one popup, adding debugging info to nsMenuPopupFrame::SetPopupPosition (this method determines the location where the popup appears) would let us know whether the popup was being positioned incorrectly.

Comment 30

[Kent James (:rkent)]

Here are some observations.

1)

Comment 31

[Kent James (:rkent)]

(oops)

Here are some observations.

1. In DOM inspector, if I do Search/"Select element by click" and click on the falsely appearing popup in the corner, it correctly recognizes it as the original item, and moves to the viewPickerCustomViewsPopup menupopup line.

2. I added a LogMessage routine (to the error console) to add some information at the start and exit of nsMenuPopupFrame::SetPopupPosition, and that caused the false popup to disappear. (That is, this bug was no longer valid).

3. Replacing the LogMessage with a printf, the problem reappeared. SetPopupPosition is entered once, and exits at the bottom only once, even though I get two paintings of the popup (one correct, one incorrect). The values of xpos, ypos at the exit seem reasonable (for example 27961, 4230).

Where would you suggest I look next?

Comment 33

[David Humphrey (:humph)]

Attachment: Notifications window in top-left, resized

I wonder if what I'm seeing is this bug.  I get the notification window in the top-left and shrunk to almost nothing, as seen in the attached screenshot.

Comment 34

[Kent James (:rkent)]

(In reply to comment #33)
> Created an attachment (id=389176) [details]
> Notifications window in top-left, resized
> 
> I wonder if what I'm seeing is this bug.  I get the notification window in the
> top-left and shrunk to almost nothing, as seen in the attached screenshot.

I occasionally get the same notification window, but the character seems quite different to me than this bug. For example, I can close that notification window, while the junk on the screen from this bug cannot be removed.

Comment 35

[Kent James (:rkent)]

Attachment: Apply attachment 353441 from bug 404314 to 1.9.1

From discussions in the affiliated Thunderbird bug 488381, the false popup display does not appear in 1.9.2, and the difference has been traced to attachment 353441 [details] [diff] [review] from bug 404314. This patch is identical to that one, with line numbers updated to a more recent version of the original file. Because bug 404314 already has > 200 comments, and the issue of this bug does not seem to be related to the discussions there, I am moving the request to apply that patch for 1.9.1 here. I'd like to run this for a couple of days in my normal setup to confirm that this bug no longer occurs with this patch before requesting approval for 1.9.1. If someone else seeing these symptoms could run the same patch and confirm that it works, that would also be good.

Comment 36

[Kent James (:rkent)]

For reasons that I cannot explain, today I started getting the symptoms of this bug in a debug build. When I do, I get the following assertion when the error occurs:

###!!! ASSERTION: Creating widget for MenuPopupFrame with children: '!mGenerated
Children && !GetFirstChild(nsnull)', file c:/tb/test/src/mozilla/layout/xul/base
/src/nsMenuPopupFrame.cpp, line 229

This is the same assertion from comment 115 of bug 404314, which led to the creation of the attachment which is the proposed fix for this bug.

Comment 37

[Mark Banner (:standard8)]

(In reply to comment #36)
> For reasons that I cannot explain, today I started getting the symptoms of this
> bug in a debug build. When I do, I get the following assertion when the error
> occurs:
> 
> ###!!! ASSERTION: Creating widget for MenuPopupFrame with children:
...
> This is the same assertion from comment 115 of bug 404314, which led to the
> creation of the attachment which is the proposed fix for this bug.

cc'ing roc to get his input.

Comment 38

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What input do you need? I think the patch in comment #35 seems good

Comment 39

[Mark Banner (:standard8)]

(In reply to comment #38)
> What input do you need? I think the patch in comment #35 seems good

I was a bit concerned about comment 36...

Comment 40

[Kent James (:rkent)]

(In reply to comment #39)
> (In reply to comment #38)
> > What input do you need? I think the patch in comment #35 seems good
> 
> I was a bit concerned about comment 36...

Comment 36 was meant to reassure any watchers that the issue seen in this bug is indeed related to the issue that the original patch attachment 353441 [details] [diff] [review] was designed to correct. It was not meant to raise any red flags.

Comment 41

[Mark Banner (:standard8)]

(In reply to comment #40)
> Comment 36 was meant to reassure any watchers that the issue seen in this bug
> is indeed related to the issue that the original patch attachment 353441 [details] [diff] [review] was
> designed to correct. It was not meant to raise any red flags.

Ok, sorry for the noise, I misunderstood it.

Comment 42

[Kent James (:rkent)]

Comment on attachment 396295 [details] [diff] [review]
Apply attachment 353441 [details] [diff] [review] from bug 404314 to 1.9.1

Requesting approval for 1.9.1.4  This patch was previously reviewed and landed in bug 404314 in 1.9.2, and has been baking there for 8 months. There were no tests in the original patch. It is a simple one-line patch with little risk, but solves a problem causing a serious usability issue to a minority of TB and SM users.

Comment 43

[Daniel Veditz [:dveditz]]

Comment on attachment 396295 [details] [diff] [review]
Apply attachment 353441 [details] [diff] [review] from bug 404314 to 1.9.1

Approved for 1.9.1.4, a=dveditz for release-drivers

Comment 44

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/38d6c5b7b3da

Comment 48

[Adam Cappio]

To be clear, while I have seen this bug sporadically under other circumstances, I can consistently 100% repro WITHOUT clicking anything by having Notepad++ running when I launch TB.  I have not tried the patched build, but I'm hoping it takes this case in to account.