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)

defect

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 4.0b7

People

(Reporter: aaronmt, Assigned: ehsan.akhgari)

References

Details

(Whiteboard: [fixed by bug 602130])

Attachments

(1 file)

Attached image Screenshot
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre

See screenshot
To elaborate textually:

The cursor in the Panorama search box is too short prior to typing. Upon typing, it adjusts to the proper height.
Severity: normal → minor
Priority: -- → P5
Whiteboard: [good first bug]
Whiteboard: [good first bug] → [good first bug][visual]
Target Milestone: --- → Firefox 4.0
Priority: P5 → P2
Assignee: nobody → mitcho
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
Blocks: 598154
OS: Mac OS X → Windows 7
Severity: minor → trivial
Priority: P2 → P3
OS: Windows 7 → All
Hardware: x86 → All
It seems that this is reproducible if you click the search icon instead of entering search simply by typing.
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.
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.
(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.
(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.
(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?
(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.
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.
(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/
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.
I filed bug 602130 to address the general case
Depends on: 585967
Blocks: 585967
No longer depends on: 585967
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]
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!
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
verified with nightly minefield builds of 20101021
Status: RESOLVED → VERIFIED
Target Milestone: Firefox 4.0b8 → Firefox 4.0b7
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: