Inconsistent show/hide behavior of mailnews location toolbar

RESOLVED FIXED

Status

--
minor
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: rsx11m.pub, Assigned: neil)

Tracking

({regression})

Trunk
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
Since the 20090807 nightly build, an empty "grippy" may show up when the location toolbar is hidden, and inconsistently disappear and reappear. This toolbar is shared with the search toolbar when both are visible. In some cases, both the opened toolbar and a grippy may be visible:

(1) default - grippy visible for closed location toolbar
(2) open grippy, disappears, combined location/search bar
(3) View > Hide > Location bar, grippy disappears
(4) View > Hide > Search bar, toolbar disappears
(5) close and reopen mailnews window, grippy reappears
(6) View > Show > Location bar, toolbar reappears
(7) View > Show > Search bar, grippy remains visible
(8) click on grippy and it disappears

Last win32 nightly working fine is 20090806, where no grippy was shown when the location toolbar is hidden.
(Reporter)

Comment 1

9 years ago
Created attachment 393764 [details]
Various stages of the location toolbar

These are screendumps showing stages (1), (2), (3), and (7).
(Reporter)

Comment 2

9 years ago
Also reproduced with Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3pre) Gecko/20090811 SeaMonkey/2.0b2pre nightly build, thus all platforms.
Severity: normal → minor
OS: Windows XP → All
Hardware: x86 → All

Comment 3

9 years ago
Bug 506492 is in the right timeframe.
Blocks: 506492

Comment 4

9 years ago
goToggleLocationToolbar() and OnLocationToolbarAttrModified() probably need to be fixed. Collapsing the Location toolbar by clicking on the grippy moves the searchbar to the message pane.
(Assignee)

Comment 5

9 years ago
Created attachment 394832 [details] [diff] [review]
I think this fixes things

* Changed from using "collapsed" to using "hidden"
* Was able to use goToggleToolbar and remove goToggleLocationToolbar
* Forced current column as hiding the toolbar confuses the tree selection
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #394832 - Flags: review?(iann_bugzilla)

Comment 6

9 years ago
Comment on attachment 394832 [details] [diff] [review]
I think this fixes things

There does not seem to be anything about migrating the collapsed to hidden state so on first start with this patch applied you still get the collapsed grippy state which you have to sort out, after that no issues.
Attachment #394832 - Flags: review?(iann_bugzilla) → review-
(Assignee)

Comment 7

9 years ago
(In reply to comment #6)
> (From update of attachment 394832 [details] [diff] [review])
> There does not seem to be anything about migrating the collapsed to hidden
> state so on first start with this patch applied you still get the collapsed
> grippy state which you have to sort out, after that no issues.
Unfortunately due to bug 506492 we don't know why the toolbar is in the collapsed state; it could be that the user genuinely clicked the grippy.

Comment 8

9 years ago
Well when I first start SM after applying the patch, the location toolbar is showing collapsed in the UI but the View->Show/Hide->Location Toolbar is unchecked so in that case surely we should be doing something to fix it up?
(Assignee)

Comment 9

9 years ago
(In reply to comment #8)
> Well when I first start SM after applying the patch, the location toolbar is
> showing collapsed in the UI but the View->Show/Hide->Location Toolbar is
> unchecked so in that case surely we should be doing something to fix it up?
I'm not sure what you're getting at here but maybe you mean that the checked state of the menu should be copied to to the hidden state of the toolbar? I wouldn't want to leave code for that in permanently though.

Comment 10

9 years ago
(In reply to comment #9)
> (In reply to comment #8)
> > Well when I first start SM after applying the patch, the location toolbar is
> > showing collapsed in the UI but the View->Show/Hide->Location Toolbar is
> > unchecked so in that case surely we should be doing something to fix it up?
> I'm not sure what you're getting at here but maybe you mean that the checked
> state of the menu should be copied to to the hidden state of the toolbar? I
> wouldn't want to leave code for that in permanently though.
Yes, some sort of migration code. What is the window of where users would have been affected by this?
(Assignee)

Comment 11

9 years ago
Last 3 weeks or so, so anyone using nightlies since just after beta 1.

Updated

9 years ago
Attachment #394832 - Flags: review- → review+

Comment 12

9 years ago
(In reply to comment #11)
> Last 3 weeks or so, so anyone using nightlies since just after beta 1.

Okay, probably not worth doing anything then if we can get it in for beta 2.
(Assignee)

Comment 13

9 years ago
Pushed changeset 42bada3ecb39 to comm-central.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.