Closed Bug 365917 Opened 18 years ago Closed 18 years ago

[proto] Invite Attendee: initial busy info (color: red == No info) not displayed

Categories

(Calendar :: Lightning Only, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: ulf.stroehler, Assigned: michael.buettner)

Details

STR

1. try to invite someone which is neither in your local address book nor provided by LDAP (e.g. disable LDAP)

2. in the Invite Attendee (free/busy) dialog type in the name of that person


Finding

the color scheme changes from red to white while typing the name of an unknown person

Expectation

the color scheme should always display red as long as no info about the attendee is available
I'd like to add my 2 cents here, because I would expect something different.
- Initially the grid should be white (as it is today).
- While typing the attendees name the grid color should not change.
- After finishing typing the Free/Busy information should be requested.
- If no Free/Busy information is available it should turn red.
First, initially the grid is currently colored pink (no information), so I'm not sure if I misunderstood what you wrote in the previous comment ???
Second, "After finished typing" is something that can't easily be determined. The user can enter a valid cal-id or an email-address. since i don't know whether or not the entered string is "valid" i display the "no information" indicator (pink row). as soon as the calendar server is able to retrieve the free/busy information i correctly display the result (free or busy). So, to get down to the point, I don't know if the entered string is "finished", so the previous comment is impossible to model as described.
in reply to comment #2:

> since i don't know
> whether or not the entered string is "valid" i display the "no information"
> indicator (pink row)

great. that seems very well aligned with the user's expectation.

And that's what I'd been missing. I remember the indicator turning to white although there was obviously no information available.

However this issue magically doesn't occur any longer in recent nightlies hence is NOT REPRODUCIBLE and therefor INVALID. It behaves as you say in comment #2.

Resolving issue INVALID.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
(In reply to comment #2)
> Second, "After finished typing" is something that can't easily be determined.
Could you use "onblur" to not when the user moves out of that textbox?
(In reply to comment #2)
> Second, "After finished typing" is something that can't easily be determined.
Could you use "onblur" to note when the user moves out of that textbox?
(In reply to comment #5)
> Could you use "onblur" to note when the user moves out of that textbox?
This was one option i already thought about in order to detect this case, but it would be nice to receive the free/busy-data before leaving the input-field.
(In reply to comment #3)
> However this issue magically doesn't occur any longer in recent nightlies hence
> is NOT REPRODUCIBLE and therefor INVALID. It behaves as you say in comment #2.
> 
> Resolving issue INVALID.

Ulf, not reproducible bugs are considered as WORKSFORME in the Mozilla world.
Resolution: INVALID → WORKSFORME
You need to log in before you can comment on or make changes to this bug.