Closed
Bug 596619
Opened 15 years ago
Closed 15 years ago
panning the page during findbar use shouldn't dismiss the findbar
Categories
(Firefox for Android Graveyard :: General, defect)
Firefox for Android Graveyard
General
Tracking
(fennec2.0b2+)
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
fennec | 2.0b2+ | --- |
People
(Reporter: madhava, Assigned: vingtetun)
References
Details
Attachments
(1 file)
4.99 KB,
patch
|
mfinkle
:
review+
|
Details | Diff | Splinter Review |
The findbar (find in page) should not disappear just because a user is panning the page. Quite often the user will have to pan the page to see the context of what the findbar has found. The keyboard can certainly be dimissed, but the findbar should remain so that the user can keep finding, and can refocus the field to bring the keyboard back up. Only tapping off of the findbar should dismiss it.
Reporter | ||
Updated•15 years ago
|
blocking2.0: --- → ?
Comment 1•15 years ago
|
||
As an aside, I don't think the Form Assistant should disappear when panning either. Just mentioning since these "bars" are related in code.
Updated•15 years ago
|
blocking2.0: ? → ---
tracking-fennec: --- → ?
OS: Mac OS X → All
Hardware: x86 → All
Version: 1.9.2 Branch → Trunk
Updated•15 years ago
|
tracking-fennec: ? → 2.0b2+
Assignee | ||
Comment 2•15 years ago
|
||
The patch prevent the Find Helper to be considered as a popup. The patch also include a fix for getting the coordinate of the selection when it is in a sub-document, and an another one for not showing the title bar on some cases.
Assignee: nobody → 21
Attachment #477137 -
Flags: review?(mark.finkle)
Comment 3•15 years ago
|
||
Comment on attachment 477137 [details] [diff] [review]
Patch
>diff -r 5860ea9d73d5 chrome/content/content.js
> receiveMessage: function findHandlerReceiveMessage(aMessage) {
>- let controller = this._selectionController.getSelection(Ci.nsISelectionController.SELECTION_NORMAL);
>- if (!controller.rangeCount) {
>+ let selection = this._fastFind.currentWindow.getSelection();
>+ if (!selection.rangeCount) {
Add a comment above this block to let us know what this code is trying to do
>- let range = controller.getRangeAt(0);
> let scroll = Util.getScrollOffset(content);
>- let rect = range.getBoundingClientRect();
>- rect = new Rect(scroll.x + rect.left, scroll.y + rect.top, rect.width, rect.height);
>+ for (let frame = this._fastFind.currentWindow; frame != content; frame = frame.parent) {
>+ let rect = frame.frameElement.getBoundingClientRect();
>+ let left = frame.getComputedStyle(frame.frameElement, "").borderLeftWidth;
>+ let top = frame.getComputedStyle(frame.frameElement, "").borderTopWidth;
>+ scroll.add(rect.left + parseInt(left), rect.top + parseInt(top));
>+ }
Add some comments here too
>+ let rangeRect = selection.getRangeAt(0).getBoundingClientRect();
>+ let rect = new Rect(scroll.x + rangeRect.left, scroll.y + rangeRect.top, rangeRect.width, rangeRect.height);
And here, just to complete the function
Attachment #477137 -
Flags: review?(mark.finkle) → review+
Updated•15 years ago
|
Whiteboard: [fennec-checkin-postb1]
Comment 4•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [fennec-checkin-postb1]
![]() |
||
Comment 5•15 years ago
|
||
verified FIXED on builds:
Mozilla/5.0 (Maemo; Linux armv71; rv:2.0b6pre) Gecko/20100930 Namoroka/4.0b7pre Fennec/4.0b1pre
and
Mozilla/5.0 (Android; Linux armv71; rv:2.0b6pre) Gecko/20100930 Namoroka/4.0b7pre Fennec/4.0b1pre
Follow up bugs filed: 600844 , 600845, 600846
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•