Closed
Bug 128676
Opened 22 years ago
Closed 22 years ago
Cannot select any search engine options
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: momoi, Assigned: joki)
References
()
Details
(Keywords: testcase, Whiteboard: [adt1])
Attachments
(2 files)
172 bytes,
text/html
|
Details | |
1.66 KB,
patch
|
joki
:
review+
jst
:
superreview+
jud
:
approval+
|
Details | Diff | Splinter Review |
** Observed with 2002-03-02 Win32 trunk build on Win2K ** I looked for a duplicate of this bug because it is such an obvious bug but could not easily find one. So Iam finling one juts in case. Starting around 2002-02-24 or 2002-02-25 builds, I am not able to select any of the Seach engine choices on Netscape Home above. This worked Ok with 2002-02-23 Win32 trunk build.
Comment 1•22 years ago
|
||
This is really bad, it doesn't look like the combobox is getting the Mouse Events need a reduced testcase
Updated•22 years ago
|
Target Milestone: --- → mozilla1.0
Comment 4•22 years ago
|
||
WFM using 2002030508 build on WinXP.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 5•22 years ago
|
||
Cannot confirm WFM with 2002-03-05 Win32 trunk build on Win 2000. Re-opening...
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 6•22 years ago
|
||
Ok, I see the problem now. The first time I click and select a search engine it works fine. If I click on the combobox after selecting an item it does not display the dropdown. Subsequent attempts to bring up the dropdown fail.
Comment 7•22 years ago
|
||
Strange ... when you click on a textfield and then click back on the select the select will open again.
Comment 8•22 years ago
|
||
*** Bug 132636 has been marked as a duplicate of this bug. ***
Comment 10•22 years ago
|
||
The underlying problem is that SetFocus(FALSE) and then SetFocus(TRUE) are being called on the combobox when you click on it a second time. I've begun to reduce the testcase, and it's beginning to look like scrolling=no ...
Comment 11•22 years ago
|
||
OK, so in this testcase, if you delete any of the attributes it no longer happens. If you set the height of the iframe so that it's smaller than the <select>, it works. If you remove frameborder=0, it works. If you make the margins wide so that the <select> is farther down, it works. I suspect frameborder=0.
Comment 12•22 years ago
|
||
Problem is focus is being erroneously set to false and then true when the select is near the top of the screen. To Events.
Assignee: jkeiser → joki
Status: REOPENED → NEW
Component: HTML Form Controls → Event Handling
Comment 13•22 years ago
|
||
*** Bug 135346 has been marked as a duplicate of this bug. ***
Comment 14•22 years ago
|
||
*** Bug 130316 has been marked as a duplicate of this bug. ***
Comment 15•22 years ago
|
||
We should really get this fixed for RC1 if at all possible.
Blocks: 134771
Keywords: mozilla1.0+
Assignee | ||
Comment 16•22 years ago
|
||
Conveniently I just put this fix together for a bugscape bug. Takes care of this one, too.
Assignee | ||
Comment 17•22 years ago
|
||
Comment on attachment 78989 [details] [diff] [review] Patch Per email with roc+moz Sounds good to me! Do you have a bugzilla bug for this? Stick an r=roc+moz on your patch when you do :-).
Attachment #78989 -
Flags: review+
Comment 18•22 years ago
|
||
Comment on attachment 78989 [details] [diff] [review] Patch sr=jst
Attachment #78989 -
Flags: superreview+
Updated•22 years ago
|
Attachment #78989 -
Flags: approval+
Comment 19•22 years ago
|
||
Can this be landed today? We're about to do an RC1 and this shouldn't miss the train. Thanks.
Comment 20•22 years ago
|
||
can you check this into the trunk and update this bug when it's been tested.
Assignee | ||
Comment 21•22 years ago
|
||
Fixed on trunk. Marking fixed as per instructions. Still needs approval and checkin on branch.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Comment 22•22 years ago
|
||
I am still seeing the problem with 2002041408 on win2k. I filed Bug 135346 which was marked as a duplicate of this one. The test site that I am still seing the error is: http://filebox.vt.edu/users/jeisinge/mozbug/iframebug.html
Assignee | ||
Comment 23•22 years ago
|
||
Yes, I expect you would still see the error in the 2002041408 build. It wasn't fixed until midafternoon so it wouldn't have made the 8am build. Please try a later build.
Comment 24•22 years ago
|
||
It doesn't appear that this has landed on the 1.0 branch. Can you give us a status update on branch landing?
Comment 25•22 years ago
|
||
Asa, no adt1.0.0+, no branch landing. This has been in trunk for 2 days so we should be good to go...
Comment 26•22 years ago
|
||
Gerardo - Here's another bug we need verified asap. thanks!
Comment 27•22 years ago
|
||
rakesh, please verify this bug is fixed in the trunk. The adt needs to know it's tested before the fix is checked into the branch. thanks!
Comment 28•22 years ago
|
||
Verified on the build 2002-04-16-06-trunk on Win 2000.
Status: RESOLVED → VERIFIED
Comment 29•22 years ago
|
||
adt1.0.0+ on behalf of the adt. Please check into the branch today and add fixed1.0.0 to the keyword field.
Comment 30•22 years ago
|
||
I am still seeing the problem with 2002041711 (RC1) on win2k. see http://filebox.vt.edu/users/jeisinge/mozbug/iframebug.html
Comment 31•22 years ago
|
||
Jacob: this hasn't been check into the branch yet, so won't make RC1. But someone should really check it into the branch :)
Comment 33•22 years ago
|
||
Verified on the branch build 2002-04-19-08-1.0.0 on Win 2000 machine. " verified 1.0.0 "
Keywords: verified1.0.0
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•