Closed
Bug 594804
Opened 14 years ago
Closed 14 years ago
Cursor position indicator needs height adjustment in Panorama search field
Categories
(Firefox Graveyard :: Panorama, defect, P3)
Firefox Graveyard
Panorama
Tracking
(Not tracked)
VERIFIED
FIXED
Firefox 4.0b7
People
(Reporter: aaronmt, Assigned: ehsan.akhgari)
References
Details
(Whiteboard: [fixed by bug 602130])
Attachments
(1 file)
11.42 KB,
image/png
|
Details |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre See screenshot
Comment 1•14 years ago
|
||
To elaborate textually: The cursor in the Panorama search box is too short prior to typing. Upon typing, it adjusts to the proper height.
Updated•14 years ago
|
Severity: normal → minor
Priority: -- → P5
Whiteboard: [good first bug]
Updated•14 years ago
|
Whiteboard: [good first bug] → [good first bug][visual]
Target Milestone: --- → Firefox 4.0
Updated•14 years ago
|
Priority: P5 → P2
Updated•14 years ago
|
Assignee: nobody → mitcho
Comment 2•14 years ago
|
||
I'm able to reproduce this, but poking around with an inspector I have no idea what the issue is. :( helpwanted indeed. I'm taking myself off this bug in the hopes that someone else may take a look at it.
Assignee: mitcho → nobody
Keywords: helpwanted
Updated•14 years ago
|
Severity: minor → trivial
Priority: P2 → P3
Updated•14 years ago
|
OS: Windows 7 → All
Hardware: x86 → All
Comment 3•14 years ago
|
||
It seems that this is reproducible if you click the search icon instead of entering search simply by typing.
Comment 4•14 years ago
|
||
OK, played around a bit here's what I've found out so far: 1. Edit the #content div, so that all events get removed 2. Now edit the #searchbox style to make it show up Result: Cursor has the correct height. 3. Now edit #searchbox style again and set it to "display: none" 4. Make it show up again Result: Cursor is broken again. Unfortunately chromebug won't let me set breakpoints on the JS(thinks there is none). My best guess is, that it has to do something with both the event handling and CSS.
Comment 5•14 years ago
|
||
OK, so removing EVERYTHING from the document and just planting a solely text input there gives me the exact same result(broken cursor height) when hiding the input and then showing it again. It appears to me that it doesn't have anything to do with the JavaScript, CSS or the HTML. Maybe it's a bug in Chrome due to the missing menu/tab bars? Can't think of anything else right now.
Comment 6•14 years ago
|
||
(In reply to comment #5) > OK, so removing EVERYTHING from the document and just planting a solely text > input there gives me the exact same result(broken cursor height) when hiding > the input and then showing it again. Do note that (at least for me) on the very first try it displays correctly, so it seems that a hidden input shown via iQ does not suffer this bug, but only ones that has been hidden using iQ.
Comment 7•14 years ago
|
||
(In reply to comment #6) > but only ones that has been hidden using iQ. Breaks for just as well when I set the style manually.
Comment 8•14 years ago
|
||
(In reply to comment #7) > (In reply to comment #6) > > but only ones that has been hidden using iQ. > > Breaks for just as well when I set the style manually. Indeed, after more testing I see this is true when you hide it via display, but if you use visibility: hidden/visible then the bug goes away. If we cannot figure out what causes the bug, a reasonable workaround might be to simply use that instead of show()/hide(). PS: as it is now, does it also show correctly on very first show (after browser start) for you?
Comment 9•14 years ago
|
||
(In reply to comment #8) > PS: as it is now, does it also show correctly on very first show (after browser > start) for you? Yes works on the very first show after restart.
Comment 10•14 years ago
|
||
This seems to be a more general bug with <input type="text" />. On any page (try it with the ones in the form above), toggle the display to 'none' and back and you will see the same behavior.
Comment 11•14 years ago
|
||
(In reply to comment #10) > This seems to be a more general bug with <input type="text" />. On any page > (try it with the ones in the form above), toggle the display to 'none' and back > and you will see the same behavior. Confirmed in Gecko/20101004 Firefox/4.0b7pre I've made a test case where you can try it out for several values of display; it does not appear that the bug is triggered if you re-enable the input with display="inline" or display="", but both "block" and "inline-block" trigger it. http://www.geeksbynature.dk/bugs/cursorPosition/
Comment 12•14 years ago
|
||
After further testing, it appears to me that the bug is also only triggered if the input has been focused before it is hidden the first time. To be clear, if I hide the input before it has been focused, then I find it impossible to trigger the bug later. If this is correct, then a temporary workaround could be to hide the input on load in panorama, instead of via css.
Comment 13•14 years ago
|
||
I filed bug 602130 to address the general case
Updated•14 years ago
|
Assignee | ||
Comment 14•14 years ago
|
||
My patch in bug 602130 also fixes this issue. For the record, this is far from a trivial bug! ;-)
Assignee: nobody → ehsan
No longer blocks: 585967
Severity: trivial → normal
Keywords: helpwanted
Whiteboard: [good first bug][visual] → [will be fixed by bug 602130]
Comment 15•14 years ago
|
||
Just wanted to give a huge thanks to Christian, Ricky, and Ivo for jumping on this bug and the rather amazing forensic work they did. I had no idea that this bug, which I thought was a good first bug, was going to be so dastardly!
Assignee | ||
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [will be fixed by bug 602130] → [fixed by bug 602130]
Target Milestone: Firefox 4.0 → Firefox 4.0b8
Comment 16•14 years ago
|
||
verified with nightly minefield builds of 20101021
Status: RESOLVED → VERIFIED
Updated•14 years ago
|
Target Milestone: Firefox 4.0b8 → Firefox 4.0b7
Updated•8 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•