Closed
Bug 488381
Opened 15 years ago
Closed 15 years ago
List of tags is statically displayed in the upper left corner.
Categories
(Thunderbird :: Mail Window Front End, defect)
Thunderbird
Mail Window Front End
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 423955
Thunderbird 3.0b4
People
(Reporter: domi, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [as repro steps in comment 10][no l10n impact][has patch in bug 423955])
Attachments
(3 files)
68.20 KB,
image/png
|
Details | |
50.38 KB,
image/jpeg
|
Details | |
2.89 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1b4pre) Gecko/20090414 Lightning/1.0pre Shredder/3.0b3pre When I choose the 'tags' filter from the 'view' button in the mail toolbar, the widget will open at the correct location *and* in the upper left corner of the MainWindow. While the correct widget behaves correctly, the duplicated one will stay where it is and the menu items that are now hidden won't react on the mouse pointer anymore. Access via keyboard shortcuts or arrow keys is still possible. Reproducible: Always Steps to Reproduce: 1. Click on (mail toolbar) -> view -> tags 2. 3. Actual Results: The list of tags will be displayed at the correct location AND in the upper left corner of the main window; this additional widget won't disappear. Expected Results: The tags widget should open close to the button without any further appearances. I'm using a localised Shredder build with a nightly lightning build (see Build Identifier). Further add-ons: British English Dictionary 1.19, Lightning Nightly Updater 0.9.081202, Provider for Google Calendar 0.6pre, ToneQuilla 0.2.20090223, Worteliste von ... (German dictionary) 20060716 If this bug is really new (I could not find it though), I'll try to investigate whether a fresh profile or a different OS will restore the normal behaviour, and/or in which build it was 'introduced'...
Reporter | ||
Comment 1•15 years ago
|
||
Comment 2•15 years ago
|
||
Contrary to my last comment in bug 423955, I am still seeing this. I suspect it is a driver problem. You don't happen to have a Logitech camera installed, do you?
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Comment 3•15 years ago
|
||
I'm going to undup but set dependent so that I can set TB3 flags on this bug, but leave the parent bug on XUL where the issue exists.
Comment 4•15 years ago
|
||
Asuth and I both see this, as well as several other reporters in bug 423955. If it turns out to be widespread, it is a serious bug that will detract from TB3. When it occurs, at least for me, it is completely reproducible, and can only be fixed (and must be fixed, because it blocks the File menu) by shutting down TB.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-thunderbird3?
Comment 5•15 years ago
|
||
This has been seen on Linux & Vista. No report on the mac yet, fwiw. The linux instance makes me suspect something other than a driver issue.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
OS: Windows Vista → All
Hardware: x86 → All
Updated•15 years ago
|
Keywords: regression
Comment 6•15 years ago
|
||
Davida, for this to move forward someone is probably going to have to interest a XUL developer in looking at it. This problem is completely reproducible on my Windows XP tablet computer, including in debug builds. Unfortunately I have absolutely no idea how layout works, so there is nothing that I can do by myself to isolate this. But I would be happy to work with a knowledgeable developer, adding dumps or breaks at key points to try to isolate the point of failure.
Comment 7•15 years ago
|
||
I also see this bug in the XUL-based Komodo ("Komodo Edit, version 5.1.3, build 3592, platform win32-x86.") To see it there, I do for example edit/preferences/file associations, then click the down arrow for "language". The language list then shows up both in the correct location, and in the middle of the preferences window. Perhaps Komodo Edit is more widely distributed than Shredder, and we could use their experience as a guide to how widespread this bug is likely to be.
Comment 8•15 years ago
|
||
see http://bugs.activestate.com/show_bug.cgi?id=82375 for the komodo equivalent.
Comment 9•15 years ago
|
||
I could not reproduce this on OS X using a version I built today. (changeset: 2674:e470fc7f0aa1 tag: tip user: Robert Strong <robert.bugzilla@gmail.com> date: Thu May 21 16:53:26 2009 -0700 summary: Bug 488936 - Store the install locale in its own file. r=philringnalda, r=mschroeder, r=kairo) I tried putting the View dropdown at the start, middle, and end of my toolbar, as well as making my window as big and as small as possible, and nothing I did could reproduce it on OS X. I have a Windows XP virtual machine I could test on, so I got the May 21st, 04:33 build from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/thunderbird-3.0b3pre.en-US.win32.installer.exe and tried the same set of tests, and couldn't reproduce it there either. Dominik and Kent, could one or both of you send me a screenshot of your toolbar, and indicate a place you can click that demonstrates the faulty behaviour so that I can make sure I'm doing the same thing that you are? (I'm now wondering if it's got something to do with the number of items we're trying to display... I'll have to test that out tomorrow.)
Comment 10•15 years ago
|
||
This still happens reliably for me on official Thunderbird linux nightlies (32-bit). My personal debug builds never exhibit the problem, though I build 64-bit and with accessibility disabled (otherwise many of my apps tend to lock up when thunderbird is suspended for debugging). The steps-to-reproduce are: 1) Make sure you have the view combobox anywhere on your toolbar. 2) Click on the view combobox... 3) Hover over "Tags" or "Custom Views" to cause the popup to be displayed. As soon as the popup is displayed, a duplicate copy will show up in the upper-left hand corner of the window. Interesting characteristics and behavior: - This happens for both popups, but the custom views popup is always on top of the tags list. The tags list by default is shorter than the custom view list and so does not stick out, but it's there. If you add new tags and perform steps 2 and 3 again, the phantom pop-up will update. - DOM inspector identifies the popup as living where you would expect it, and selecting the nodes for its items in the DOM inspector DOM tree causes them to get nice red borders like you would expect. I expect that part of the reason this is happening is that both of those popups have as their onpopupshowing function a function that destroys all the items in the pop-up and re-computes them. The C++ XUL code for popups seems capable of producing multiple frame objects for each popup, so that could also play a part... (I briefly looked at the problem earlier today, but gave up when it became apparent that the mechanisms DOM inspector uses probably wouldn't let me track it down... I need to reproduce the problem on a build I can attach a debugger to.)
Comment 11•15 years ago
|
||
Neil (just a wild guess but) this might be fallout from your re-write of the XUL popup code.
Comment 12•15 years ago
|
||
This shows the exact point that I select to show the problem. It is exactly where asuth describes.
Updated•15 years ago
|
Whiteboard: [as repro steps in comment 10]
Comment 13•15 years ago
|
||
(In reply to comment #10) > This still happens reliably for me on official Thunderbird linux nightlies > (32-bit). My personal debug builds never exhibit the problem. I tried a debug build as well, and it also did not show the problem.
Comment 14•15 years ago
|
||
(In reply to comment #13) >> This still happens reliably for me on official Thunderbird linux nightlies >> (32-bit). My personal debug builds never exhibit the problem. > I tried a debug build as well, and it also did not show the problem. Did anybody try running under valgrind?
Comment 15•15 years ago
|
||
I just updated my personal build to to a recent nightly, and now just clicking on a newsgroup in the folder pane causes a listof the custom views to pop up in the upper left corner. This really makes TB unusable for me at the moment.
Comment 16•15 years ago
|
||
The issue with showing the blocking in the corner only happens until I select a view from the view toolbar (which is showing view "0" due to a known bug.) Once I get a real view there, then I no longer have the corner popup of this bug.
Comment 17•15 years ago
|
||
I have some new observations on this bug. After following the STR in comment 10 to make this bug appear, I can make the false copy of the popup disappear by right clicking on the toolbar, and selecting customize. After I do this, the bug will no longer appear for the particular popup that showed the bug until I restart TB. This has now become my standard workaround for this.
Comment 18•15 years ago
|
||
I'd like to update on some work I have done on this. I've tried to trace the issue through the layout code (which is greatly complicated because I cannot use a debugger). Starting at the point where the item is written to the screen, I can see the incorrect output being written to the screen, and trace it several levels up the call stack. But I am quite unfamiliar with the layout code, and after more than a day of this I gave up. But I am convinced it is some sort of layout bug, where the menupopup's menuitems are added to a display list at a time where they should not be visible, and where their anchor element does not have the correct location defined. The best approach to this bug would be to fix the underlying layout bug, but without such a fix I have started to investigate workarounds. As a possible workaround, I tried to keep the menupopup (or its menuitems) hidden until the point they are needed. I've attached a patch that shows this approach. It mostly works, but there are still some cases where I can make the false displays appear even with this patch, though the most common occurances have disappeared. I am also not convinced that this patch is actually managing the issue, it may instead just be altering the timing on my system to mask the problem. If I could figure out XUL events that I could use to hide and unhide the popup to avoid the layout bug this might work, but I an not convinced I have found the correct events (if they even exist). So at this point, I will probably investigate an alternate workaround, which is to quit defining the second-level menupopups in XUL, but instead add them dynamically to the menu when needed. I would appreciate any help or comments on this. The only qualification I have to work on this is that I see the bug reliably on one of my systems.
Comment 19•15 years ago
|
||
Comment 20•15 years ago
|
||
So it sounds like the menupopup is being painted when it is not yet visible. Could be a view problem of some sort.
Would be pretty easy to track down if it could be reproduced in a debug build... In particular I'd set gDumpPaintList to 1 and reproduce the bug and the debug output would be very useful... Maybe someone can remove enough #ifdef DEBUGs to get to the point where you can get that output in an opt build?
Comment 22•15 years ago
|
||
From what I can see, the gDumpPaintList occurs in nsLayoutUtils::PaintFrame. I've already confirmed that I can see the error there with my own printf statements. Where are the decisions being made that send lists of items to display to paint there? That decision is being made incorrectly, and I believe it is upstream of nsLayoutUtils::PaintFrame. But it is easy enough for me to modify the code to get the printouts if that would be helpful. I'm really willing to do any reasonable amount of prints and tracing, but I need some guidance. As we said earlier, at the moment this is only occurring in release-type builds, not my debug builds. But it is completely reproducible for me on the machine where it occurs, and I can easily modify the release builds I do there to display any useful information.
If you use --enable-debug-modules=ALL_MODULES and do a release build, can you reproduce the bug in that? That would help a lot.
I'm actually not sure what normally prevents the contents of popups from being painted in their containing window.
Comment 25•15 years ago
|
||
(In reply to comment #24) > I'm actually not sure what normally prevents the contents of popups from being > painted in their containing window. The view isn't visible. It's set as not visible when a popup is initialized in nsBoxFrame::CreateViewForFrame. Maybe something is going wrong within there?
We don't take account of view visibility while building display lists, though. I looked, and nsMenuFrame::BuildDisplayList has no code to descend into the popupList children of nsMenuFrame, so that's not the problem. But it looks like the children of nsPopupSetFrame are in the regular child list. Perhaps we should override nsPopupSetFrame::BuildDisplayList to never descend into its children?
Comment 27•15 years ago
|
||
I did a release build with "ac_add_options --enable-debug-modules=ALL_MODULES" and the bug still appears. I have no idea what that option does however.
It means you can attach a debugger and get stack traces with symbols, set breakpoints, etc.
Comment 29•15 years ago
|
||
(In reply to comment #26) > We don't take account of view visibility while building display lists, though. > > I looked, and nsMenuFrame::BuildDisplayList has no code to descend into the > popupList children of nsMenuFrame, so that's not the problem. The screenshot shows that this is a <menulist> so menu frames would be the problem. > But it looks like the children of nsPopupSetFrame are in the regular child list. They are also put into the popupList. Is this bug a regression from something? Do we know that something is?
Comment 30•15 years ago
|
||
This bug is the Thunderbird version of core bug 423955. That bug is noted to be a regression from bug 279703. I'm pretty sure that I confirmed that by building without that bug, but I don't see a record of that in the bug comments.
Comment 31•15 years ago
|
||
(In reply to comment #30) > This bug is the Thunderbird version of core bug 423955. I'm not really clear of the difference between the two bugs. Both are Thunderbird bugs with just a slightly different piece of the UI. > That bug is noted to be a regression from bug 279703. I'm pretty sure > that I confirmed that by building without that bug, I would have thought it not possible to extract the changes from that bug and undo them.
Comment 32•15 years ago
|
||
(In reply to comment #31) > > I'm not really clear of the difference between the two bugs. Both are > Thunderbird bugs with just a slightly different piece of the UI. > The only real difference as far as I am concerned is that this bug is for Product:Thunderbird, and therefore allows setting of the blocking-thunderbird3 flag, while the other bug is for Core:XUL, and therefore shows up correctly to developers. But note that I am neither the OP nor Assignee of either bug, just the guy who sees it reliably and will talk about it.
Comment 33•15 years ago
|
||
(In reply to comment #27) > I did a release build with "ac_add_options --enable-debug-modules=ALL_MODULES" > and the bug still appears. I have no idea what that option does however. (In reply to comment #28) > It means you can attach a debugger and get stack traces with symbols, set > breakpoints, etc. You're thinking of --enable-debugger-info-modules (the =yes (synonym for =ALL_MODULES) is optional). --enable-debug-modules turns on NS_ASSERTION etc.
Updated•15 years ago
|
Whiteboard: [as repro steps in comment 10] → [as repro steps in comment 10][no l10n impact]
Comment 34•15 years ago
|
||
I tried a TB release build based on 1.9.2 instead of 1.9.1, and I no longer saw this bug.
Comment 35•15 years ago
|
||
I have managed to get a symbols build with --enable-debugger-info-modules, and I am able to both run the debugger to trace code, as well as see the bug in that build. But for now, I am investigating understanding why it works on 1.9.2 but not 1.9.1. The earliest TB 1.9.2 nighties, from 2009-01-09, do not exhibit this bug. I'm trying to see the de-regression range on 1.9.2 on my own builds at the moment. Perhaps there is a single 1.9.2 bug that we could land on 1.9.1 and solve our problems.
Comment 36•15 years ago
|
||
After a weekend of builds to do a binary search of what fixed my issue in 1.9.2, we have a winner: mozilla revision 22941 fixes it, which is attachment 353441 [details] [diff] [review] from bug 404314. I have also confirmed that adding that one-line fix to my mozilla 1.9.1 standard TB 3.0 build fixes the issue there as well. So it seems like the correct thing to do is to request 1.9.1 landing of attachment 353441 [details] [diff] [review]. Unfortunately that attachment is only a minor piece of the issue discussed in bug 404314, which has over 200 comments and claims to be fixed in another bug. So I'm not sure of the best approach here, but it seems like bringing up the issue of this bug in bug 404314 is not the correct approach. What I would suggest is that we add the attachment that fixes this issue to either this bug or to the equivalent bug 423955, and request 1.9.1 for one of those.
Depends on: 404314
That sounds good, please do so!
Updated•15 years ago
|
Whiteboard: [as repro steps in comment 10][no l10n impact] → [as repro steps in comment 10][no l10n impact][has patch in bug 423955]
Updated•15 years ago
|
Target Milestone: --- → Thunderbird 3.0b4
Comment 38•15 years ago
|
||
Assigning to rkent, since he's been doing the driving here.
Assignee: nobody → kent
Comment 39•15 years ago
|
||
There's nothing left of this bug, now that bug 423955 has landed. I'm going to dupe it to that bug. This only existed to allow the blocking-tb3 flag.
Status: NEW → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → DUPLICATE
Updated•15 years ago
|
Assignee: kent → nobody
You need to log in
before you can comment on or make changes to this bug.
Description
•