Closed Bug 339565 Opened 19 years ago Closed 19 years ago

google.com textfield autocomplete shows unexpectedly with gok

Categories

(Firefox :: Disability Access, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 2 beta2

People

(Reporter: ginnchen+exoracle, Assigned: nian.liu)

References

()

Details

(Keywords: access, fixed1.8.1)

Attachments

(2 files)

1) open www.google.com, make sure firefox saved some values for the text field. 2) focus the text field (it is focused by default when www.google.com is loaded) autocomplete dropdown isn't shown at this time 3) "ui grab" with gok, click "About Google" button in gok window 4) "About Google" page rendered with textfield autocomplete dropdown at the middle of the page I'm not sure if this bug belongs to A11y, but I can only reproduce it with gok.
Attached image Screenshot
btw: if focus is not in the textfield as step 2), this bug can't be reproduce.
at-poke shows first autocomplete get the focus then link "about google" get the focus.
Assignee: nobody → nian.liu
Attached patch patchSplinter Review
mimic real ui event.
Attachment #224400 - Flags: review?(ginn.chen)
Attachment #224400 - Flags: review?(ginn.chen) → review?(aaronleventhal)
Attachment #224400 - Flags: review?(aaronleventhal) → review+
Attachment #224400 - Flags: superreview?(roc)
Attachment #224400 - Flags: superreview?(roc) → superreview?(neil)
Comment on attachment 224400 [details] [diff] [review] patch > nsIPresShell *presShell = doc->GetShellAt(0); ... >- content->HandleDOMEvent(presShell->GetPresContext(), &clickEvent, nsnull, >- NS_EVENT_FLAG_INIT, &eventStatus); >+ presShell->HandleDOMEventWithTarget(content, &downEvent, &eventStatus); >+ presShell->HandleDOMEventWithTarget(content, &upEvent, &eventStatus); >+ presShell->HandleDOMEventWithTarget(content, &clickEvent, &eventStatus); These calls can theoretically destroy the pres shell. Before, there was only one call, so it didn't matter. However, you now need to store the pres shell in an nsCOMPtr to ensure that it continues to exist. sr=me with that fixed.
Attachment #224400 - Flags: superreview?(neil) → superreview+
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: access
Resolution: --- → FIXED
> These calls can theoretically destroy the pres shell. Before, there was only Neil, can you help me know how that destroy the pres shell? > one call, so it didn't matter. However, you now need to store the pres shell in > an nsCOMPtr to ensure that it continues to exist. sr=me with that fixed. >
aaron, we need to change nsIPresShell *presShell = doc->GetShellAt(0); to nsCOMPtr<nsIPresShell> presShell = doc->GetShellAt(0); as Neil addressed.
(In reply to comment #6) >can you help me know how that destroy the pres shell? Basically, any event can invoke JavaScript which can close the window.
Okay, made the nsCOMPtr<> change.
Attachment #224400 - Flags: approval1.8.1?
Flags: blocking-firefox2?
Target Milestone: --- → Firefox 2 beta2
We'll plus the patch when beta 1 clears...
Flags: blocking-firefox2? → blocking-firefox2+
Comment on attachment 224400 [details] [diff] [review] patch You are cleared to land, sir.
Attachment #224400 - Flags: approval1.8.1? → approval1.8.1+
Whiteboard: [has approval, needs checkin]
Checking in src/base/nsAccessible.cpp; /cvsroot/mozilla/accessible/src/base/nsAccessible.cpp,v <-- nsAccessible.cpp new revision: 1.165.2.8; previous revision: 1.165.2.7 done
Keywords: fixed1.8.1
Whiteboard: [has approval, needs checkin]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: