Ubuntu
firefox-3.0 package

Resize corner grab stays visible after maximize

Bug #385816 reported by positivek
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
Mozilla Firefox 3.6
firefox (Ubuntu)
Fix Released
Low
Unassigned
firefox-3.0 (Ubuntu)
Won't Fix
Low
Unassigned
firefox-3.5 (Ubuntu)
Triaged
Low
Unassigned

Bug Description

Binary package hint: firefox

1. Start up Nautilus or Firefox.
2. Make sure it is unmaximized and smaller than the screen.
3. Notice that in the bottom right of the window there is a "grab" area for resizing
4. Maximize it.
5. --> Notice that in the bottom right of the window there is still a "grab" area for resizing. It should not be visible.

In Nautilus, the grab area after maximizing simply does nothing and does not go away. When I mouse over it, the mouse pointer does not change. See screenshot.

In Firefox 3.0.10, the grab area after maximizing makes a mouse-over change the mouse to a SE-corner resize pointer. The grab area remains until at least the following occur:
 * Attempt to use it (after the mouse-up) or click on it.
 * Switch to another window and then switch back.

Occurs with different Gnome Themes (Human-Clearlooks and Mist tested).

Does NOT occur with Eye of Gnome.

Ubuntu 9.04.
Gnome 2.26.1
Nautilus 2.26.2
Firefox 3.0.10
Eye of Gnome 2.26.1
Linux 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

See original description
Revision history for this message
In , Peter-vanderwoude (peter-vanderwoude) wrote :

not only that, you can actually resize a maximized window using the grippy.
The state of the minimize/maximize button changes when you change the window with the grippy from maxed to another size

Revision history for this message
In , Mike Connor (mconnor) wrote :

Doesn't seem like a blocker, doesn't seem harmful in our testing, if not 100% correct.

Revision history for this message
In , Gevazeichner (gevazeichner) wrote :

I've noticed that when moving your focus out of the FF window and back to it - the gripper disappears again.

Revision history for this message
In , Scanorama346 (scanorama346) wrote :

Can confirm all of the above with

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042906 Minefield/3.0pre ID:2008042906

Revision history for this message
In , Scanorama346 (scanorama346) wrote :

Created an attachment (id=318569)
Grippie present on maxmised window

Revision history for this message
In , Kevin Brosnan (kbrosnan) wrote :

*** Bug 432289 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Kliu (kliu) wrote :

*** Bug 431688 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Robert "Anaerin" Johnston (anaerin) wrote :

Essentially, what's happening here is that the attribute "sizemode" isn't changing to "maximized" when it happens. You can alt-tab away and alt-tab back and the value then changes, making the CSS rule(s) that depend on it work properly. What needs to happen is on maximize, update the "sizemode" attribute.

Revision history for this message
In , Ria-klaassen (ria-klaassen) wrote :

*** Bug 456965 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Ria-klaassen (ria-klaassen) wrote :

*** Bug 446632 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Ehume-pshrink (ehume-pshrink) wrote :

Perhaps an additional clue: when Forecastfox is set to appear at the right end of the status bar, the grippy (in the Maximized window mode) appears to the left of the Forecastfox elements, but to the right of all other statusbar elements. Using Forecastsfox's context selection of Options, then canceling, will make the grippy disappear. Resizing and maximizing will cause the grippy to again appear between the normal statusbar elements and Forecastfox.

Revision history for this message
In , Blerner (blerner) wrote :

Is bug 251599 at all related (i.e., would fixing this attribute fix full-screen too)?

Revision history for this message
In , Nickolay Ponomarev (asqueella) wrote :

Created an attachment (id=355604)
sizemode/windowState manual test

This can be used to test how window.minimize(), maximize(), restore() calls and minimizing/maximizing the window manually affects window.windowState property and the sizemode attribute (the latter is used to determine visibility of the grippy).

Revision history for this message
In , Nickolay Ponomarev (asqueella) wrote :

Please check with the next trunk nightly - should be fixed.

Revision history for this message
In , Ray Murphy (ol-rrm-2008) wrote :

I am not seeing this in build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090203 Minefield/3.2a1pre - Build ID: 20090203033842

Revision history for this message
In , Supernova00 (supernova00) wrote :

(In reply to comment #15)
> I am not seeing this in build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9.2a1pre) Gecko/20090203 Minefield/3.2a1pre - Build ID: 20090203033842

It is still there using the same build. You have to click the restore down button and then click the maximize button (same button) then the grippy will still show on the maximized window.

Revision history for this message
In , Ray Murphy (ol-rrm-2008) wrote :

Kurt,

That is exactly what I did. However, it must be an add-on that is affecting things for my main-use profile. In using a plain, unadorned profile, the bug is still present.

Sorry about that.

(In reply to comment #16)
> (In reply to comment #15)
> > I am not seeing this in build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> > rv:1.9.2a1pre) Gecko/20090203 Minefield/3.2a1pre - Build ID: 20090203033842
>
> It is still there using the same build. You have to click the restore down
> button and then click the maximize button (same button) then the grippy will
> still show on the maximized window.

Revision history for this message
In , Nickolay Ponomarev (asqueella) wrote :

This is windows-only regression. It never worked on at least Mac (not sure about linux).

Revision history for this message
In , Alex Mayorga (alex-mayorga) wrote :

Still happens in Shiretoko nightlies on Vista too
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090218 Shiretoko/3.1b3pre ID:20090218033015

Revision history for this message
In , Nickolay Ponomarev (asqueella) wrote :

Bug 472258 was fixed on trunk (3.2) only, which should have fixed this issue.

comments 15&16 tested this on a build before the fix was checked in.

Revision history for this message
positivek (anonyhole) wrote :

Binary package hint: firefox

1. Start up Nautilus or Firefox.
2. Make sure it is unmaximized and smaller than the screen.
3. Notice that in the bottom right of the window there is a "grab" area for resizing
4. Maximize it.
5. --> Notice that in the bottom right of the window there is still a "grab" area for resizing. It should not be visible.

In Nautilus, the grab area after maximizing simply does nothing and does not go away. When I mouse over it, the mouse pointer does not change. See screenshot.

In Firefox 3.0.10, the grab area after maximizing makes a mouse-over change the mouse to a SE-corner resize pointer. The grab area remains until at least the following occur:
 * Attempt to use it (after the mouse-up) or click on it.
 * Switch to another window and then switch back.

Occurs with different Gnome Themes (Human-Clearlooks and Mist tested).

Does NOT occur with Eye of Gnome.

Ubuntu 9.04.
Gnome 2.26.1
Nautilus 2.26.2
Firefox 3.0.10
Eye of Gnome 2.26.1
Linux 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

Revision history for this message
positivek (anonyhole) wrote :
Revision history for this message
positivek (anonyhole) wrote :

Related?: Bug #282528 - Window resizing in the corner could be better

Revision history for this message
positivek (anonyhole) wrote :

Related: Bug #250796 - When a window is maximized, no mouse-resizing options shoud show up when placing the mouse near the window "borders"/endings.

Revision history for this message
Micah Gersten (micahg) wrote :

I was able to confirm this on Firefox 3.0.10 and Firefox 3.5pre.

affects: firefox (Ubuntu) → firefox-3.0 (Ubuntu)
Changed in firefox-3.0 (Ubuntu):
status: New → Confirmed
importance: Undecided → Low
Changed in firefox-3.5 (Ubuntu):
importance: Undecided → Low
Revision history for this message
Sebastien Bacher (seb128) wrote :

don't open random tasks for different projects having the same bug but open new bug reports rather to not spam everybody about all the other packages they are not working on and have a similar issue

affects: nautilus (Ubuntu) → ubuntu
Changed in ubuntu:
importance: Undecided → Low
status: New → Invalid
Revision history for this message
In , Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing) wrote :

This seemingly is a problem on Linux as well.

Ubuntu bug:
https://bugs.launchpad.net/bugs/385816

I have this on Shiretoko 3.5 final.

Revision history for this message
Micah Gersten (micahg) wrote :

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at:
https://bugzilla.mozilla.org/show_bug.cgi?id=419292

Changed in firefox-3.0 (Ubuntu):
status: Confirmed → Triaged
Changed in firefox-3.5 (Ubuntu):
status: New → Triaged
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Unknown → Confirmed
Revision history for this message
In , Luke-iliffe (luke-iliffe) wrote :

On windows 7 RC with the latest trunk when I maximize the window the grippy is present for a split second then disappears. This results in the expected behaviour of not being able to resize the maximized windows using the grippy.

(Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091009 Minefield/3.7a1pre ID:20091009051317)

Revision history for this message
In , Kimsey0 (jacoberen) wrote :

I'm using:
Mozilla/5.0 (Windows; U; Windows NT 6.0; da; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 GTB5 (.NET CLR 3.5.30729)
And also see this behavior, but actually it doesn't annoy me. For me, it's a feature, not a bug.
The only reason i see for changing it, is to imitate the behavior of other Windows Applications.

Would it be worth considering to keep the "bug", and actually implement it as a feature, as there's probably someone like me, who likes to resize their windows without having to click the Restore button first?

Revision history for this message
In , Nickolay Ponomarev (asqueella) wrote :

> Would it be worth considering to keep the "bug"

Possibly, but the way it worked in Firefox 3.5 was broken (code-wise) and it's fixed already in the development version. So your suggestion is effectively a request for another change.

If you care about it a lot, you could submit it separately, try to get input from the UI people, make a patch, get it reviewed and landed. Or just implement it as an extension, which should be simpler.

Revision history for this message
In , Kimsey0 (jacoberen) wrote :

Okay. If a fix's already implemented, i'll not go any further with it.
After all, this is unintentional, and might confuse some people.

Revision history for this message
In , Mvketel (mvketel) wrote :

My 2 cents: Just like Jacob I prefer this 'feature' actually I'd like to see it in the window directly if started maximized. Why would one to prefer to use 1 click and a click-drag to resize the window to its preferred size ins tead of the click-drag at once? This used to be the way in SeaMonkey 1.1.x and now it is is gone in SM 2.0 (probably following Fx) :(

Revision history for this message
In , Nickolay Ponomarev (asqueella) wrote :

So this is fixed by bug 472258, as I said before. Marking as such.

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Confirmed → Fix Released
Revision history for this message
Micah Gersten (micahg) wrote :

Firefox 3.0 is only receiving Security Updates and major bug fixes at this point.

Changed in firefox:
milestone: none → 3.6
Changed in firefox-3.0 (Ubuntu):
status: Triaged → Won't Fix
Revision history for this message
Micah Gersten (micahg) wrote :

Firefox will be the source for Firefox 3.6, so reopening this task

affects: ubuntu → firefox (Ubuntu)
Changed in firefox (Ubuntu):
status: Invalid → Triaged
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (9.6 KiB)

This bug was fixed in the package firefox - 3.6+nobinonly-0ubuntu1

---------------
firefox (3.6+nobinonly-0ubuntu1) lucid; urgency=low

  * New upstream release v3.6 (FIREFOX_3_6_RELEASE)
    + fix LP: #449744 - Firefox crashes when attempting to load Firebug 1.5
    + fix LP: #66015 - Duplicate spell checking dictionaries for every entry
    + fix LP: #132938 - tooltips dont work in sidebar
    + fix LP: #195698 - Password asked separately for each tab that requires it
                        (proxy)
    + fix LP: #239462 - tooltips disappear too fast
    + fix LP: #385816 - Resize corner grab stays visible after maximize
    + fix LP: #429476 - firefox crash on javascript page
    + fix LP: #432876 - Icons missing in Firefox searchbox drop down list
    + fix LP: #486284 - maxlength on input box can be overriden by autocomplete
    + fix LP: #501393 - Integrate Firefox notifications with notify-osd bling

  [ H. Montoliu <email address hidden> ]
  * fix LP: #361052 - firefox apport hook fails to retrieve pluginreg.dat file
  * update debian/apport/firefox-3.6.py - removed unused code and minor refactoring.

  [ Fabien Tassin <email address hidden> ]
  * Update the location of the upsteam branch now that 3.6/Namoroka has its own
    branch, and trunk moved on to 3.7
    - update debian/mozclient/firefox-3.6.conf
  * Use Namoroka instead of Shiretoko as brand name and use it for snapshots.
    Name it Namoroka in the Preferred Application UI too
    - update debian/firefox-3.6-shiretoko.desktop => debian/firefox-3.6-namoroka.desktop
    - update debian/firefox-3.6.xml
    - update debian/rules
  * Target the 'default' branch instead of tip
    - add debian/moz-rev.sh
    - update debian/mozclient/firefox-3.6.conf
  * Add firefox 3.6 to the list of Preferred Applications in Gnome
    - add debian/firefox-3.6.xml
    - update debian/firefox-3.6-gnome-support.install
  * Add ${misc:Depends} to all non-transitional packages, make firefox-3.6-dbg
    depend on firefox-3.6 with the exact same version, move -dbg packges to
    priority extra and add firefox-3.6-gnome-support-dbg
    - update debian/control
  * Update diverged patches:
    - update debian/patches/browser_branding.patch
    - update debian/patches/firefox-profilename
    - update debian/patches/ubuntu_bookmarks.patch
    - update debian/patches/lp185622_system_path_default_browser.patch
    - update debian/patches/dont_depend_on_nspr_sources.patch

  [ Alexander Sack <email address hidden> ]
  * add libnotify-dev to build-depends
    - update debian/control
  * add libiw-dev to build-depends to fix build failure
    - update debian/control
  * until we move searchplugins to a separate package provided only by the current default
    firefox, we need to make firefox-3.6 replace all the older firefox binary packages:
    firefox-3.5, firefox-3.2, firefox-3.1, firefox-3.0
    - update debian/control
  * implement MIN_SYS_DEPS approach that does not use system xulrunner
    and only a minimal set of system dependencies.
    + drop patches not required anymore:
      - delete debian/patches/dont_depend_on_nspr_sources.patch
      - update debian/patches/series
    + update browser directory provider...

Read more...

Changed in firefox (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
In , Twalker (twalker) wrote :

*** Bug 535107 has been marked as a duplicate of this bug. ***

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.