[Bug 22093] Consider adding candidatewindowshow/update/hide events and getCandidateWindowClientRect()

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22093

--- Comment #10 from Takayoshi Kochi <kochi@google.com> ---
Technically adding isCandidateWindowVisible() sounds easy, once
candidatewindowshow/hide is implemented, it just returns cached state.

Basically I want the spec to be as minimal as possible to provide bare
minimum, so this convenient function is not necessarily mandatory, and
I am also wondering the usefulness of the return value of this function,
as usually a candidate window is a short-lived UI which disappears once
the user finishes choosing a candidate.

If the method returns true, the candidate may close immediately after that,
or if it returns false, a new candidate window may appear soon after that.

So showing a UI (such as search suggestions) which may outlive the
candidate window on a location that avoids soon-disappearing window
may give weird impression on users.

Do you have a viable demo that uses this function and saves lots of code
compared to using oncandidatewindow* events, and still useful to construct
a usable UI?

I'm not completely convinced for the reasons above.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 7 November 2013 03:31:01 UTC