Closed
Bug 522217
Opened 16 years ago
Closed 16 years ago
[Mac] Missing window title after leaving the full screen mode
Categories
(Core :: Widget: Cocoa, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla1.9.3a1
| Tracking | Status | |
|---|---|---|
| status1.9.2 | --- | beta2-fixed |
People
(Reporter: whimboo, Assigned: mstange)
References
Details
(Keywords: verified1.9.2)
Attachments
(2 files, 2 obsolete files)
|
29.64 KB,
patch
|
Details | Diff | Splinter Review | |
|
20.88 KB,
patch
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1pre) Gecko/20091011 Namoroka/3.6b1pre ID:20091011033822
When you leave the full screen mode on OS X the window title is not restored and is shown as blank as long as the windows are open. Someone has to open a new tab to show the title again.
Steps:
1. Open a window with a couple of tabs
2. Enter full screen mode and leave it immediately
3. Switch between the open tabs
4. Open a new tab
After step 2 none of the open tabs show a window title even when switching through them. With step 4 the title is restored for each tab.
Flags: blocking1.9.2?
Comment 1•16 years ago
|
||
I don't see this in:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b1pre) Gecko/20091011 Namoroka/3.6b1pre ID: 20091011033822
| Reporter | ||
Comment 2•16 years ago
|
||
Still there with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b2pre) Gecko/20091022 Namoroka/3.6b2pre ID:20091022033608
Could this be a 10.5 only bug and 10.6 is not affected? Marcia, could you test this on a lab machine?
| Assignee | ||
Comment 3•16 years ago
|
||
Looking at the code, this can't really depend on whether you use 10.5 or 10.6; the code is just wrong - it doesn't save the title of the window before destroying it.
Damon, maybe you tested this with a fullscreen video instead of fullscreening the browser window?
Assignee: nobody → mstange
| Assignee | ||
Comment 4•16 years ago
|
||
| Reporter | ||
Updated•16 years ago
|
Status: NEW → ASSIGNED
Comment 5•16 years ago
|
||
This blocks bug 521744, which is a blocker; ergo, this is a blocker.
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P1
| Assignee | ||
Comment 6•16 years ago
|
||
This isn't beautiful, but I think it's what we need to do. This fixes two bugs:
- State that's only saved on the NSWindow wasn't re-imported into the new
window.
- In fullscreen mode, our window wasn't a ToolbarWindow, so setting titlebar
colors or drawintitlebar didn't work on it.
This patch moves the ownership of all that state into a common base class, "BaseWindow", so that things like titlebar colors can even be set on a BorderlessWindow.
Attachment #408019 -
Attachment is obsolete: true
Attachment #408886 -
Flags: review?(joshmoz)
| Assignee | ||
Comment 7•16 years ago
|
||
Tests passed on tryserver.
Comment on attachment 408886 [details] [diff] [review]
v1
>+- (void)importState:(NSDictionary*)aState
>+{
>+ [self setTitle:[aState objectForKey:@"title"]];
>+ [self setDrawsContentsIntoWindowFrame:[[aState objectForKey:@"drawsContentsIntoWindowFrame"] boolValue]];
>+ [self setTitlebarColor:[aState objectForKey:@"activeTitlebarColor"] forActiveWindow:YES];
>+ [self setTitlebarColor:[aState objectForKey:@"inactiveTitlebarColor"] forActiveWindow:NO];
>+}
>+
>+- (NSMutableDictionary*)exportState
>+{
>+ NSMutableDictionary* state = [NSMutableDictionary dictionaryWithCapacity:10];
>+ [state setObject:[self title] forKey:@"title"];
>+ [state setObject:[NSNumber numberWithBool:[self drawsContentsIntoWindowFrame]]
>+ forKey:@"drawsContentsIntoWindowFrame"];
>+ NSColor* activeTitlebarColor = [self titlebarColorForActiveWindow:YES];
>+ if (activeTitlebarColor) {
>+ [state setObject:activeTitlebarColor forKey:@"activeTitlebarColor"];
>+ }
>+ NSColor* inactiveTitlebarColor = [self titlebarColorForActiveWindow:NO];
>+ if (inactiveTitlebarColor) {
>+ [state setObject:inactiveTitlebarColor forKey:@"inactiveTitlebarColor"];
>+ }
>+ return state;
Please make the strings used here static variables. That way we won't get bitten by any typos. Post a new patch with that, r+. Thanks!
Attachment #408886 -
Flags: review?(joshmoz) → review+
| Assignee | ||
Comment 9•16 years ago
|
||
Attachment #408886 -
Attachment is obsolete: true
| Assignee | ||
Comment 10•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
| Reporter | ||
Comment 11•16 years ago
|
||
Looks good in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091104 Minefield/3.7a1pre ID:20091104031046
Thanks Markus.
Status: RESOLVED → VERIFIED
Version: 1.9.2 Branch → Trunk
| Assignee | ||
Comment 12•16 years ago
|
||
status1.9.2:
--- → final-fixed
| Assignee | ||
Comment 13•16 years ago
|
||
merged around bug 513158
| Assignee | ||
Updated•16 years ago
|
Attachment #410534 -
Attachment is patch: true
Attachment #410534 -
Attachment mime type: application/octet-stream → text/plain
| Reporter | ||
Comment 14•16 years ago
|
||
Verified fixed on 1.9.2 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b2pre) Gecko/20091106 Namoroka/3.6b2pre ID:20091106033745
Keywords: verified1.9.2
You need to log in
before you can comment on or make changes to this bug.
Description
•