Closed
Bug 906741
Opened 11 years ago
Closed 11 years ago
Compose window doesn't completely dismiss after sending a message in fullscreen
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(thunderbird_esr3133+ fixed)
RESOLVED
FIXED
Thunderbird 32.0
People
(Reporter: ekrem.koc, Assigned: jsbruner)
References
Details
Attachments
(3 files)
371.42 KB,
image/png
|
Details | |
371.42 KB,
image/png
|
Details | |
1.33 KB,
patch
|
mkmelin
:
review+
standard8
:
approval-comm-esr31+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812
Steps to reproduce:
Mac OS X 10.8.4.
I often use full screen for Mozilla Thunderbird. I write a new compose and this window is full screen and is the desktop is another place.
Actual results:
When I have sent a compose to someone, than I see that a window is black.
Expected results:
Can the development make: a desktop go close after I sent a compose?
Updated•11 years ago
|
Group: core-security
I have made screenshot:
http://picpaste.com/pics/Schermafbeelding_2013-08-19_om_20.49.29-RfADRTQm.1376938430.png
After I sent a compose, I saw a black desktop. Why didn't the desktop close?
Updated•11 years ago
|
Summary: Compose - Window → Suspected screen update problems involving compose window
Comment 2•11 years ago
|
||
see this with beta version from http://www.mozilla.org/thunderbird/channel/ ?
Flags: needinfo?(ekrem.koc)
If I close an address book window (full screen), than is the desktop close too. Why doesn't the desktop close after the compose window go send or close?
Assignee | ||
Comment 7•11 years ago
|
||
Yep, I'm seeing this too.
Status: UNCONFIRMED → NEW
Component: Untriaged → Message Compose Window
Ever confirmed: true
Assignee | ||
Updated•11 years ago
|
Summary: Suspected screen update problems involving compose window → Compose window doesn't completely dismiss after sending a message in fullscreen
Comment 8•11 years ago
|
||
(In reply to Josiah Bruner [:JosiahOne] from comment #7)
> Yep, I'm seeing this too.
Josiah, could you pls add steps to reproduce? Is "fullscreen" a special feature of MAC OS windows?
Assignee | ||
Comment 9•11 years ago
|
||
(In reply to Thomas D. from comment #8)
> (In reply to Josiah Bruner [:JosiahOne] from comment #7)
> > Yep, I'm seeing this too.
>
> Josiah, could you pls add steps to reproduce? Is "fullscreen" a special
> feature of MAC OS windows?
Sure thing.
This "fullscreen" is a Cocoa (OS X) API that we use for certain windows (including this one). My guess is that the compose window dismissal forgot about this serparate behavior when it was developed. So although the window is closed, we still need to dismiss the fullscreen state. It's possible that this needs to be done on the widget end of things, since usually OS X applications aren't closed while in fullscreen mode.
STR are simple enough:
Open compose window
Click the fullscreen button in the top right corner of the window
Send message.
Examine behavior.
Fix:
I'll probably do this when I have a chance, but in case anyone wants to take a stab, the idea is simple.
Before we close the window, exit the fullscreen state using Cocoa's enterFullScreen:withOptions: method. We might have a way to accomplish the same method via JS, but I wouldn't know what it is off the top of my head.
Reporter | ||
Comment 10•11 years ago
|
||
I see that works it; a desktop go close after I sent a compose to someone. Maybe I have adjusted a configuration editor. I had disable all:
- full-screen-api.allow-trusted-requests-only
- full-screen-api.content-only;true
- full-screen-api.enabled
- full-screen-api.pointer-lock.enabled
Reporter | ||
Comment 11•11 years ago
|
||
Can someone fix this bugs please?
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → josiah
Status: NEW → ASSIGNED
Assignee | ||
Comment 12•11 years ago
|
||
This should fix the issue.
Attachment #8428471 -
Flags: review?(mkmelin+mozilla)
Assignee | ||
Updated•11 years ago
|
Hardware: x86 → All
Version: 17 → Trunk
Assignee | ||
Updated•11 years ago
|
Flags: needinfo?(mconley)
Assignee | ||
Comment 13•11 years ago
|
||
Mike, so what we were trying yesterday (Well, today, but it will be tomorrow when you read this), didn't work.
Apparently we've lost reference to the window object by DoCommandClose() or something similar, because I can not toggle fullscreen off at that point.
We may still have to use the current solution, but I'm open to other ideas.
Assignee | ||
Comment 14•11 years ago
|
||
By the time we arrive at DoCommandClose() I mean.
Comment 15•11 years ago
|
||
Comment on attachment 8428471 [details] [diff] [review]
Fix.
Review of attachment 8428471 [details] [diff] [review]:
-----------------------------------------------------------------
Don't have a mac, but this looks totally reasonable to me. r=mkmelin
Attachment #8428471 -
Flags: review?(mkmelin+mozilla) → review+
Comment 17•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 32.0
Assignee | ||
Comment 18•10 years ago
|
||
Comment on attachment 8428471 [details] [diff] [review]
Fix.
[Approval Request Comment]
Regression caused by (bug #): OS X Lion
User impact if declined: Trying to send a message while in full screen will not dismiss the space, forcing the user to dismiss the space themselves.
Testing completed (on c-c, etc.): On comm-beta.
Risk to taking this patch (and alternatives if risky): Very low, minimal JS patch and has been on c-c, c-a, and c-b already.
Attachment #8428471 -
Flags: approval-comm-esr31?
Updated•10 years ago
|
Attachment #8428471 -
Flags: approval-comm-esr31? → approval-comm-esr31+
Updated•10 years ago
|
tracking-thunderbird_esr31:
--- → 33+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 20•10 years ago
|
||
Updated•10 years ago
|
status-thunderbird_esr31:
--- → fixed
Keywords: checkin-needed
You need to log in
before you can comment on or make changes to this bug.
Description
•