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)
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
Comment 1•18 years ago
|
||
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.
Assignee | ||
Comment 2•18 years ago
|
||
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.
Reporter | ||
Comment 3•18 years ago
|
||
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
Comment 4•18 years ago
|
||
(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?
Comment 5•18 years ago
|
||
(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?
Assignee | ||
Comment 6•18 years ago
|
||
(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.
Comment 7•18 years ago
|
||
(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.
Description
•