Closed Bug 646374 Opened 12 years ago Closed 7 years ago

Windows taskbar button order is altered when transitioning into full-screen mode from normal mode

Categories

(Core :: Widget: Win32, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox5 - ---

People

(Reporter: alice0775, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/3d0784802ce6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110329 Firefox/4.2a1pre ID:20110329145917

Order of taskbar button is changed when a browser became full-screen mode.

This does not happen on Firefox3.6.x and Google Chrome 12.0.717.0 canary build.

*This does not happen on ubuntu10.04 Gnome2.30.2.

Steps to Reproduce:
1. Start Minefield with new profile
2. Open other windows applications
    --- pay attention to the order of taskbar buttons
        (Ex. [Minefield][App A][App B])
3. Enter Full-screen mode( Press F11 on Minefiled).
4. Press Windows key
   ---The position of the button of Minefield changes in the right-side end of the taskbar
      ([App A][App B][Minefield])
5. Restore window mode (Press F11 again)
   ---(Same as Step4)
      ([App A][App B][Minefield])


Actual Results:
  The order of windows taskbar buttons is changed

Expected Results:
  Should not change the order.
Sorry, 
>This does not happen on Firefox3.6.x and Google Chrome 12.0.717.0 canary build.
This happens on Google Chrome 12.0.717.0 canary build.
This does not happen on Firefox3.6.x ,IE8 and Oprea11 .
Component: General → Widget: Win32
QA Contact: general → win32
After landing Bug 648902,

*Switching window mode between Maxmized mode and Full screen mode : Position of the task bar button is retained.
*Switching window mode between Normald mode and Full screen mode : The taskbar button jumps to the right.

The browser should behave in the same way,
And  I think,  in both cases, the position of the task bar button should be retained .
Blocks: 648902
Summary: The order of windows taskbar buttons is changed when Minefield became full-screen mode → Taskbar button jumps to the right when Minefield became full-screen mode
The problem is that hiding a window removes it from the task bar, and when it is unhidden, Windows is re-adding it to the task bar.  Knowing this, we know...

1) This would not be a problem if the user has task bar grouping and the items belonging to Firefox are grouped, or if on NT6.1, Firefox is pinned.

2) Since bug 648902 eliminates the window-hide if it is maximized, that it would "fix" this bug for that particular scenario is to be expected.

Is there a way to hide the window without removing it from the taskbar?  Hmm, I wonder if ITaskbarList::AddTab can be used to force a window to remain on the taskbar even if hidden.  If not, then we really should find a way to resolve bug 634586 using something less blunt than hiding the window (or just back it out, since this bug affects usability while bug 634586 is simply cosmetic).
>(In reply to comment #3)
> 1) This would not be a problem if the user has task bar grouping and the items
> belonging to Firefox are grouped, or if on NT6.1, Firefox is pinned.
In this case, Open two browsers like[browser1][browser2], 
then browser1 toggle fullscreen , resulting [browser2][browser1]
This is bad. it should keep the display order of browsers thumbnail.
Summary: Taskbar button jumps to the right when Minefield became full-screen mode → Windows taskbar button order is altered when transitioning into full-screen mode
(In reply to comment #3)
> Is there a way to hide the window without removing it from the taskbar?  Hmm, I
> wonder if ITaskbarList::AddTab can be used to force a window to remain on the
> taskbar even if hidden.

Just tried that idea: nope, that won't help us.  AddTab does have the ability to force a hidden window onto the taskbar, but of course, if the window is already hidden, then it's too late: the button has already been removed, and all that it'll to is re-add the button, which gets us nowhere.  Calling AddTab prior to setting SW_HIDE is pretty much a noop: Windows doesn't refcount show-on-taskbar commands so preemptive calls to AddTab will not prevent the removal of the taskbar button if we toggle SW_HIDE.

So, there is simply no way to toggle SW_HIDE on a window and not have it lose its taskbar button.  Period.  Which means that the hide-the-window solution in bug 634586 must go: either we find another way to address that cosmetic issue, or we back it out (IMO, usability issue trumps cosmetic issue).

Hiding the window never seemed right in the first place; seems very shoehorned.  I wonder if we can use SetWindowRedraw instead; it seems like it would be a better fit for bug 634586 anyway.

I'll give SetWindowRedraw a try some time tomorrow if Jim doesn't do so.
Is this still occurring on Aurora?  It looks like the patch landed before the merge.
(In reply to comment #6)
> Is this still occurring on Aurora?  It looks like the patch landed before the
> merge.

For non-maximized->fullscreen transitions, yes, it still happens.  Bug 648902 landed before Aurora, so maximized->full is fine.
Not holding 5 beta on this issue.
Depends on: 617052
Assignee: nobody → netzen
- Removed the show/hide from Bug 634586  so that the taskbar buttons are not re-ordered.
- Cleaned up other code that is not needed to be called which causes window moves which makes the transition look so bad.
- Transitions now look even better than with the show/hide for me now for normal mode.  Maximized to fullscreen looks perfect like IE now (but without the autohide bug of IE).
Attachment #554241 - Flags: review?(jmathies)
Did the MarkFullscreenWindow call effect this?
not directly but I think some of the other things we were doing were to try and allow the auto hide taskbars to actually hide, even know they weren't in the end.
Comment on attachment 554241 [details] [diff] [review]
Patch for reordering and nicer transitions

I’m not seeing the improvement here. For one thing this brings back bug 575855. It also reintroduces the original problem in bug 634586, which you can see pretty well on heavy content sites like http://garfield.com/comics/todayscomic.html.

What I see when going from a normalized window to full screen:

1) The window takes the desktop
2) normalized window (chrome + content) shifts to the upper left hand side of the window
3) Content refreshes, repainting to full screen dimensions
4) full screen nav bar fills in

Prior to this, everything shifted from a normalized window to a fully painted full screen window without any anomalies. On smaller screens this is harder to see, but having heavy content helps. Granted the fix in bug 634586 wasn’t perfect due to the side effects noted in this bug, but I think it was better than what we had.

Also, this introduces a new bug where when you restore, there’s no titlebar. I also see a strange glass transition where the glass is first painted gray, and then as glass. This is probably due to a loss of a size mode event normally sent to content so that it is aware of the transition.
Attachment #554241 - Flags: review?(jmathies) → review-
OK thanks for all this info, I'll take another stab at this with all this info.
By the way the goal is to get rid of the hiding from 634586, so that one at least was on purpose.  I probably need to use a heavier content site like you mentioned to see it.
The widget event code can be touchy. It's unfortunate it's that way but it is. I've tried to clean it up and solidify it over time but I'm not sure I've really made any progress. What we really need is a better test framework, but that is hard to do due to desktop and os variances.
I'd love to get a brain dump of any thoughts or ideas you have on a test framework.
> What I see when going from a normalized window to full screen:

Don't those 4 steps currently happen when maximizing as well?
With FF6 I can see it push to the top left and then back to the normal position when maximizing.
(In reply to Brian R. Bondy [:bbondy] from comment #17)
> > What I see when going from a normalized window to full screen:
> 
> Don't those 4 steps currently happen when maximizing as well?
> With FF6 I can see it push to the top left and then back to the normal
> position when maximizing.

Yep. bug 634586 didn't mess with that transition.

If you're interested in poking at this some more looking for a better fix, you might look at the WM_NCCALCSIZE event. Preservation of the client area is control through the settings set there and through a return constant. It might be possible to better control where windows moves our client area to during some of these transitions.
Summary: Windows taskbar button order is altered when transitioning into full-screen mode → Windows taskbar button order is altered when transitioning into full-screen mode from normal mode
This annoying behavior occurs on  DOM FullScreen API too

STR
1.Confirm browser window sizemode is not maximized (Window[A] should be in normal sizemode)
2.Open http://www.mozilla.org/projects/firefox/prerelease.html
3.Open new window(Ctrl+N)(Window[B])
4.Switch back Window[A]
 --- (Window[A])(Window[B]) in taskbar now
5.Click fullscreen icon in the video control
6.Exit fullscreen (press ESC)

Actual Results:
order of taskbar button was changed.
(Window[B])(Window[A]) in taskbar

This does not happen if windows[A] is in maximized mode in Step1.
Assignee: netzen → nobody
Fixed by bug 1160014 patch 3.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Depends on: 1160014
You need to log in before you can comment on or make changes to this bug.