Closed Bug 910700 Opened 12 years ago Closed 11 years ago

When the check spelling window appears, a portion of the bottom of the window is cut off until the window is moved slightly

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Version:
24 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: thee.chicago.wolf, Unassigned)

References

Details

Attachments

(2 files)

check-spelling-cut-off.jpg
150.05 KB, image/jpeg
Details
cut-off-even-more.jpg
32.20 KB, image/jpeg
Details
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 (Beta/Release) Build ID: 20130803200314 Steps to reproduce: I compose a new email and have a misspelled word. I clicked Send and it brings up spell check to check spelling automatically before sending a message. The Check Spelling window appears in the top left corner but suddenly the Check Spelling window cuts off the bottom portion of the window just below the Stop and Send buttons (see image). Dragging the window even only a pixel in *any* direction make the bottom portion of the Check Spelling Window re-appear/fill back in. Not sure if it is related to bug 531833. Actual results: The Check Spelling window appears but the bottom portion of the window gets cut off just below the Stop and Send buttons. Expected results: The Check Spelling window should appear and the bottom portion of the window should not get cut off just below the Stop and Send buttons.
Just a note that this is using TB24B2.
I noticed the cut-off screen also in nightly, aurora and beta, but I didn't see the window would get displayed correctly after moving it a bit. You can try to remove localstore.rdf from you profile directory and see if that's a workaround, since that file stores all toolbar customizations, window sizes, tree sort orders and settings like that.
Status: UNCONFIRMED → NEW
Component: Untriaged → Mail Window Front End
Ever confirmed: true
Removing localstore.rdf doesn't change a thing about it, the window keeps coming up too small. Moving it a little resizes it to make it big enough. I've also seen this using other complete themes.
Yes, same here. I see the same behaviors on XP SP3 and Win7 SP1 x64. It's not OS specific or related to even being in safe mode without add-ons.
Still present on 24.0.1 and 25.0b1.
Attached image cut-off-even-more.jpg —
Seems with 25.0b1 it has gotten worse.
Windows 7 (x64) Thunderbird 24.1.1 Default Theme 24.1.1 In SeaMonkey, this same problem has been observed in other dialogue windows; see bug #812050. Thus, is it certain that in Thunderbird this problem is limited to the Check Spelling dialogue window?
Still happening in TB 27b1 Build 2. Can not resize it.
Windows 7 (x64) Thunderbird 24.3 There are many bug numbers for this: 531833 544284 544286 910700 It was not present in TB v17 but reappeared when I upgraded from v 17 to v24.0 It isn't critical, nor severe, nor major but it is an example of lack of attention to detail when testing new releases by developers. It would appear that the code to save the 'last position displayed' is not being saved properly. Apparently there's code which is meant to support transition from the 'old way' of storing preferences to the 'new way'. If this specific data was/is stored in the 'old way' but not copied to the 'new way' when TB is opened, then the values will be '0,0' in the 'new way'. Possibly when TB is closed, the values for this may be copied to the 'old way' but to no avail, because they won't be copied back the next time TB is opened. Checking the other bugs, this has been a reoccurring problem since TB v 3.0 so there must be some documentation in the code to assist in locating and fixing it again... :), right Blake? I didn't add a screenshot, there are plenty already. Jim
Windows 7 (x64) Thunderbird 24.3 There are many bug numbers for this: 531833 544284 544286 910700 It was not present in TB v17 but reappeared when I upgraded from v 17 to v24.0 It isn't critical, nor severe, nor major but it is an example of lack of attention to detail when testing new releases by developers. It would appear that the code to save the 'last position displayed' is not being saved properly. Apparently there's code which is meant to support transition from the 'old way' of storing preferences to the 'new way'. If this specific data was/is stored in the 'old way' but not copied to the 'new way' when TB is opened, then the values will be '0,0' in the 'new way'. Possibly when TB is closed, the values for this may be copied to the 'old way' but to no avail, because they won't be copied back the next time TB is opened. Checking the other bugs, this has been a reoccurring problem since TB v 3.0 so there must be some documentation in the code to assist in locating and fixing it again... :), right Blake? I didn't add a screenshot, there are plenty already. Jim
Well let's be all happy this coding sloppiness introduced after V 17.x is not part of an airliner landing system that upon approach suddenly retracts the flaps.... You get what you pay for....
(In reply to rcdorner from comment #14) > Well let's be all happy this coding sloppiness introduced after V 17.x is > not part of an airliner landing system that upon approach suddenly retracts > the flaps.... > > You get what you pay for.... It seems that the devs like working on new things (features) but no one wants to fix 'old' things despite the large claim on the main site: "We are Mozilla Doing good is part of our code". Since they aren't paid there's little motivation for the "OK to take it and work on it" approach. One fix would be to make the prior versions available, v 17 worked just fine IMHO.
Please realize such negative comments don't help us fix these bugs and in fact make it so we feel less likely to do so. I can't reproduce on OS X, so aceman, could you take a look at this?
I observe something similar in bug 789744. However we are stuck there. It looks like some problem in the XUL toolkit.
This appears to be fixed in TB 28.0b1 on Win7 X64 SP1. Can someone verify on XP? I don't have an XP box handy at the moment.
It looks like it is fixed in 28.0b1 on my Windows 7 Pro SP1 X32.
An observation: I slowed down the CPU for testing purposes in an unrelated matter. By accident I started at one point TB and noticed something interesting. Hope it helps whoever works on the bug. As with the low deliberate slow CPU speed all screen draws and API calls took their time. I had an email unsent and TB eventually asked if I want it to send now. I clicked "yes" not thinking that I had the CPU slowed down. To my surprise the spell check window appeared correctly sized for about 3 seconds. after the CPU caught up with its duties, the spell check window suddenly resized at the bottom, now displaying the reduced size, the bug issue discussed here. So, somewhere in the execution it is right and then gets for unknown reasons [faulty] resized!
As of 28.0b1 this appears fixed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: