Open Bug 672085 Opened 13 years ago Updated 2 years ago

If window only has one tab, dragging tab to detach should temporarily hide window frame

Categories

(Firefox :: Tabbed Browser, defect)

defect

Tracking

()

Tracking Status
firefox57 - wontfix

People

(Reporter: fryn, Unassigned)

References

Details

Attachments

(3 files, 1 obsolete file)

If a window only has one tab, dragging that tab should temporarily hide the window frame.

I couldn't find a method to hide chrome windows that is available via the IDL.
The two conditions that I would like such a method to satisfy if possible:
- a panel that is a descendent of the window remains visible
- background-image: -moz-element(#content) still displays the contents of <tabbrowser/>
unbitrot.
Attachment #546361 - Attachment is obsolete: true
CC'ing Jim, since he might know more about how Chromium and IE9 achieved this type of effect.
I have an idea for how to do this on Windows Vista/7, since we already have most if not all the platform support we need for it, but I have no idea for other operating systems.

Prototype for Vista/7 coming soon.
Summary: If window only has one tab, dragging tab should temporarily hide window frame → If window only has one tab, dragging tab to detach should temporarily hide window frame
What's your idea for Windows? Maybe we can do it the same way on the Mac side.
(In reply to comment #5)
> What's your idea for Windows? Maybe we can do it the same way on the Mac
> side.

-moz-appearance: none; makes the window frame disappear when Aero Glass is enabled.
By "window frame", do you mean the window contents, too? Or would you hide those separately?
But maybe we can get a more natural API for this. nsIWidget::Show should already be able to handle multiple show/hide calls per window lifetime, it's just not exposed via IDL yet. For example you could add show() and hide() to nsIDOMChromeWindow and implement it in nsGlobalWindow by simply calling widget->Show(true/false), similar to how minimize() and restore() are implemented.
Do you want to give that a try?
Markus, this is what I meant, but it's a massively unstable hack that I'd never ship. (I'll upload a screencast of it shortly.)

Felipe also suggested exposing Show() and Hide() too. We'll try that and see how it works.
Here's a screencast of what the above hack does when it doesn't glitch.
Ah, interesting. But now I'm confused: Do you want to go for the Chrome or for the Safari style, i.e. move a life-sized frameless window or something thumbnail-sized? Wouldn't the Safari style be more consistent with the current tab detaching visuals?
(In reply to comment #10)
> Ah, interesting. But now I'm confused: Do you want to go for the Chrome or
> for the Safari style, i.e. move a life-sized frameless window or something
> thumbnail-sized? Wouldn't the Safari style be more consistent with the
> current tab detaching visuals?

Either works for me. The above hack to try to make it Chrome/IE9-style was just me experimenting with what is possible with our platform.

Yes, the Safari style is more consistent with the current visuals and probably easier to implement. We'll likely go with a Safari style animation, which Show() and Hide() will hopefully enable.
(In reply to comment #11)
> Either works for me. The above hack to try to make it Chrome/IE9-style was
> just me experimenting with what is possible with our platform.

Ah, I see.
If this feature is done after 16th august (merge) will it land in the current aurora or nightly build?
Doesn't this idea sort of conflict with Bug 674723? I mean how do you drag a tab into the bookmark bar if you are dragging the whole window (including the bookmark bar)?
(In reply to Jonathan Haas from comment #14)
> Doesn't this idea sort of conflict with Bug 674723? I mean how do you drag a
> tab into the bookmark bar if you are dragging the whole window (including
> the bookmark bar)?

If this ever gets anywhere the plan is to disable that feature. One can still drag the favicon to save, but no other browsers do this anyway.
[Tracking Requested - why for this release]: it's needed in FF 57, new and modern and is used in new browsers.

Release Note Request (optional, but appreciated): Please in FF 57.
[Why is this notable]: it's modern and is used by other browsers.
[Affects Firefox for Android]: no
[Suggested wording]: moving tab between windows.
[Links (documentation, blog post, etc)]:
Flags: needinfo?(jonatas.eletrica)
Won't fix for Firefox 57.
(In reply to jonatas.eletrica from comment #16)
> [Tracking Requested - why for this release]: it's needed in FF 57, new and
> modern and is used in new browsers.
> 
> Release Note Request (optional, but appreciated): Please in FF 57.
> [Why is this notable]: it's modern and is used by other browsers.
> [Affects Firefox for Android]: no
> [Suggested wording]: moving tab between windows.
> [Links (documentation, blog post, etc)]:

Needs to be fixed in Firefox 57.
Flags: needinfo?(jonatas.eletrica)
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 14 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dao+bmo)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: