520738 - Today pane doesn't remember the expanse state if the splitter has been dragged from collapsed state.

Status: RESOLVED FIXED

(Calendar :: Lightning Only, defect)

Description

[Decathlon]

With bug 445304 has been introduced the mode dependent width and state of the todaypane panel.
It doesn't work if the todaypane is in expanse state achieved dragging the splitter from a collapsed starting position.
Instead, it works fine if the expanse state is achieved by clicking the grippy from a collapsed starting position.

Reproducible:
always

Steps to reproduce:
1. collapse the todaypane dragging the today-pane-splitter to the extreme right or with a click on the grippy;
2. drag the splitter to the left until todaypane reappears;
3. change mode (to mail, calendar or task);
4. turn back to the previous mode;

Actual Results:
todaypane is collapsed

Expected Results:
today pane not collapsed

If in step 2 you click on the grippy to get the expanse state, then the issue doesn't occur.

Comment 1

[Decathlon]

Attachment: [short] patch

I verified that, when the splitter is dragged to the extreme right to collapse the todaypane, the splitter state becomes "collapsed" like should be. From this collapsed position, when you drag the splitter to the left, todaypane becomes open, but splitter state gets no value (i.e. getAttribute("state") returns nothing) and not an "open" value like it should be. Instead, clicking the grippy, the state becomes correctly "open". I verified this inside function 'storeWidthAndState()' which is called (by the splitter event handler 'oncommand') to store the splitter state for the current mode.

Since on MDC is written that, for splitters, 'state' attribute is automatically update when the splitter is moved, is the splitter's behavior mentioned above normal?

The attached patch merely stores in 'modesplitterstate' attribute an "open" value when the state is null to handle this situation.

I also tried another patch that changes the splitter state to "open" with a function called by 'onmouseup' handler. The change would happen after a "dragging" state has been detected. Since the 'onmouseup' handler is called before 'oncommad', it would prepare the right splitter state for the second one (so a right "open" value can be stored in 'modesplitterstate' attribute).

Philipp, when you have time could you tell me what is the right approach to this problem?

Comment 2

[Philipp Kewisch [:Fallen][📱📆]]

Decathlon, I can't reproduce this with the latest nightly. The approach is correct though. Can you retest?

Comment 3

[Decathlon]

I've just tested on WIn XP SP2 with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2pre) Gecko/20100207 Lightning/1.0b2pre Lanikai/3.1b1pre

Lightning 1.0b2pre BuildID=20100217034126

(Not sure if Thunderbird is the last version, I've downloaded it from here:
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/)

and the bug is still there with every mode: mail, calendar, task.

Comment 4

[Decathlon]

OK, now I've found the latest builds for Thunderbird and Lightning, and I can confirm the bug, maybe a "Windows only" bug?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100220 Lightning/1.1a1pre Shredder/3.2a1pre;

Lightning 1.1a1pre BuildID=20100220075106;

Win XP SP2.

Comment 5

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 404829 [details] [diff] [review]
[short] patch

Martin, do you still have a windows machine to test? If so, please review. I still can't reproduce on linux.

Comment 7

[Markus Adrario [:Taraman]]

Comment on attachment 404829 [details] [diff] [review]
[short] patch

I can reproduce it on windows.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.5pre) Gecko/20100506 Lightning/1.0b2pre Lanikai/3.1b2pre

Taking the review.

Comment 8

[Markus Adrario [:Taraman]]

Comment on attachment 404829 [details] [diff] [review]
[short] patch

>-    let splitter = document.getElementById('today-splitter');
>+    let splitterState = document.getElementById('today-splitter').getAttribute("state");
>     todaypane.setModeAttribute("modewidths", todaypane.width);
>-    if (splitter.getAttribute("state")) {
>-        todaypane.setModeAttribute("modesplitterstates", splitter.getAttribute("state"));
>-    }
>+    todaypane.setModeAttribute("modesplitterstates", splitterState ? splitterState : "open");
> }
The indentation of the last line is one tab too less.
I also would place this line directly after the "let splitterState =", to have it in context.

Since the patch is bitrotten, I had to fix it anyway.
So I'll attach a debitrotten version with the above fixed.

I was thinking if there could be other states, when the splitterState gets "null", but it seems there are none.

Since the behaviour is not like the MDC suggests, we should file a core bug, to have this clarified.

r=markus

Comment 9

[Markus Adrario [:Taraman]]

Attachment: debitrotten patch V3

The debitrotten patch

Comment 10

[Justin Wood (:Callek)]

http://hg.mozilla.org/comm-central/rev/936a574f8a79

Comment 11

[[e-mail]]

I am still getting the original behavior outlined by Decathlon.  Am running Lightning nightly from 31 July with TBird 3.1.1 on Ubuntu 10.04.  I can see Markus' patch in calendar/base/content/today-pane.js...	

Is this a regression?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2pre Thunderbird/3.1.1

Comment 13

[Philipp Kewisch [:Fallen][📱📆]]

Backported to comm-1.9.2 <http://hg.mozilla.org/releases/comm-1.9.2/rev/59beb6dac31e>

a=philipp