Closed Bug 256989 Opened 17 years ago Closed 5 years ago

"find" highlight prevents caret from working in form input fields

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 553975

People

(Reporter: ian, Unassigned)

References

(Depends on 1 open bug, )

Details

STEPS TO REPRODUCE
   1. Click the URL link above.
   2. Press "/".
   3. Type "test".
   4. Press "highlight.
   5. Click on the form field at the end (on the "b").
   6. Press left arrow (<-) 8 times.

ACTUAL RESULTS
   Cursor doesn't move into highlighted section.

EXPECTED RESULTS
   Cursor moves through highlight.
Odd that it lets you highlight even though it claims "Phrase not found".  It
probably shouldn't highlight things it can't find.
Moreover, highlights in forms don't disappear when you deactivate highlighting
from the Find toolbar.
(In reply to comment #1)
> Odd that it lets you highlight even though it claims "Phrase not found".  It
> probably shouldn't highlight things it can't find.
IMHO highlight means "make my search more visible": it's a global setting.
*** Bug 261394 has been marked as a duplicate of this bug. ***
This bug is made more annoying by bug 250414 (can't un-highlight stuff in form
fields).
A solution could be used as in my extension (Advanced Highlighter Button):
After highlight immedialty clear hightling into textboxes.
*** Bug 271791 has been marked as a duplicate of this bug. ***
*** Bug 259814 has been marked as a duplicate of this bug. ***
Assignee: firefox → nobody
OS: Windows 2000 → All
QA Contact: fast.find
Hardware: PC → All
Summary: highlight breaks form fields → highlight breaks form (input) fields
Version: 1.0 Branch → Trunk
Summary: highlight breaks form (input) fields → "find" highlight prevents caret from working in form input fields
*** Bug 340861 has been marked as a duplicate of this bug. ***
*** Bug 343466 has been marked as a duplicate of this bug. ***
Depends on: 263683
*** Bug 354364 has been marked as a duplicate of this bug. ***
Duplicate of this bug: 370570
Duplicate of this bug: 371905
Product: Firefox → Toolkit
The fix on bug 263683 doesn't anything. This issue is still present in current nightly builds.
I just filed bug 451526, which might be the reason why this bug isn't fixed by the fix for bug 263683.
Depends on: 451526
Duplicate of this bug: 422579
> The fix on bug 263683 doesn't anything.

Well, the caret can now at least enter the highlighted area, which it couldn't before. Progress :-) Sadly, you still can't see it until it leaves the highlighted area.
Duplicate of this bug: 454835
Some printf debugging seems to suggest that the problem is that the caret paints first, then the selection colours paint over it.
Component: Find Toolbar → Layout: Block and Inline
Product: Toolkit → Core
QA Contact: fast.find → layout.block-and-inline
Component: Layout: Block and Inline → Layout
QA Contact: layout.block-and-inline → layout
So, although it wouldn't have regressed this at the time it landed, as findbar highlighting was still mucking with the DOM, I've found from undoing the patch from bug 349477 now makes this work (and fixes bug 451526 also).

roc: any thoughts?
A patch that fixes this without regressing 349477 should be doable --- display lists are very flexible. Want to have a go?
Confirm the bug in Firefox 3.0.10
This WFM in 3.5.1. Any idea what fixed this?
(In reply to comment #17)
> > The fix on bug 263683 doesn't anything.
> 
> Well, the caret can now at least enter the highlighted area, which it couldn't
> before. Progress :-) Sadly, you still can't see it until it leaves the
> highlighted area.

Ahh, okay, that's what I'm seeing. So should bug 505057 be duped to this one, or should this one be closed?
Duplicate of this bug: 505057
Fix range:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7300722add8a&tochange=82d527d82812
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 553975
You need to log in before you can comment on or make changes to this bug.