133825 - "Keep this window open after publishing is complete" closes too fast

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[sujay]

using 3/27 build

this option does not work. I check it and it still stays up on
succesive publish attempts.

Comment 1

[sujay]

also another problem is that if you check that option, it is not
remembered.

Comment 2

[Charles Manske]

Read the text again.

Comment 3

[sujay]

ok these work now...however we still have a problem
where the user wants to check the option but the progress
dialog is dismissed so fast that he can't go in there anymore
to check it.

So should I re-word this bug and REOPEN it ? or file a new
one.

Comment 4

[sujay]

verified..

added a comment to bug 134182 about not being able to check "Keep this window
after publish" because dialog closes to fast.

Comment 5

[Charles Manske]

I thought there was already a bug the "Progress dialog closes too fast issue"
I guess not! This one will do just fine.

Comment 6

[Charles Manske]

Attachment: Patch v1

Use a timer to keep window up long enough for user to check/uncheck the
button. Also has improvements to layout, fixing bug 133836 -- window doesn't 
resize so you don't get annoying duplication of list items.
(There was no pt in fixing just that one, but since I had to change dialog
anyway, it is the right thing to do now.)
Fix is very straigtforward: simply put "Publishing..." as a placeholder for 
status message.

Comment 7

[Charles Manske]

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

Comment 8

[Charles Manske]

Note: When the user leaves the "Keep window..." check unchecked, the progress
dialog will stay open for minimum of 4 sec if not touched. This lets user see
messages and check/uncheck the checkbox. If you want it to go away quicker (at
any time at all, in fact), simply hit Esc or Enter key and "poof".
And if box was checked, but user unchecks it, it stays open 'immediately' (kills
existing timer).

Comment 9

[Charles Manske]

oops, last sentence is backwards. Should be:
And if box was unchecked, but user *checks* it, it stays open 'immediately' (kills
existing timer).

Comment 10

[Akkana Peck]

Comment on attachment 76780 [details] [diff] [review]
Patch v1

I'm giving my review, but I do have some misgivings.  I think "4 seconds over
and above the time it takes to publish" is way too long to make the user wait. 
It would be better if we started the timer at the beginning of the process, so
the user will see the dialog for a minimum of 4 seconds (or perhaps 3; 4 still
seems a bit long).  I think this may make our application seem pokey, "Why is
mozilla always so slow in popping down the dialog after publishing?"

But given that publishing is new and we're still working this stuff out, the
patch is probably better than the situation before the patch, so r=akkana.

I did suggest to Charley that it might be a good idea to remove the check for
gDialog.KeepOpen.checked in CheckKeepOpen(): always clear the timer in that
routine, whether the user is checking or un-checking the option.

Comment 11

[Charles Manske]

Good suggestions.
I can see tweaking this in the future: keep track of how long we've been open
since the start, and reduce the "extra time after done" if past some thresshold.
But lets keep it simple for this first round.
I'll simplify CheckKeepOpen() to always kill the timer if it exists:
function CheckKeepOpen()
{
  if (gTimerID)
  {
    clearTimeout(gTimerID);
    gTimerID = null;
  }
}

Comment 12

[Charles Manske]

This bug is critical to Publishing feature

Comment 13

[kinmoz]

Comment on attachment 76780 [details] [diff] [review]
Patch v1

sr=[e-mail]

Comment 14

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on behalf of ADT) for checkin to the 1.0 trunk.

Comment 15

[Asa Dotzler [:asa]]

Comment on attachment 76780 [details] [diff] [review]
Patch v1

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 16

[Charles Manske]

checked in

Comment 17

[michael wendell]

Verified on 04-05 trunk.

Comment 18

[Charles Manske]

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