Closed
Bug 190838
Opened 22 years ago
Closed 22 years ago
"Find stopped" keeps appearing in status bar; focused link url no longer appears
Categories
(SeaMonkey :: Find In Page, defect)
SeaMonkey
Find In Page
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: bugzilla, Assigned: aaronlev)
Details
(Keywords: regression)
Attachments
(1 file)
1.32 KB,
patch
|
Brade
:
review+
jst
:
superreview+
asa
:
approval1.3b+
|
Details | Diff | Splinter Review |
tested using 2003.01.24.08 on linux rh7.2 and 2003.01.27.03 on mac 10.2.3. whenever i start using the keyboard to navigate through a page, "Find stopped" keeps appearing in the browser window's status bar. i'd think that this text would only appear if you started typing text (with or without ' or / beforehand) to induce find as you type --which i'm *not* trying to do in this case. 1. open a link: it can be in the current window or tab, or in a new tab or window. 2. wait for the page to finish loading, so that the status bar is empty. 3. use the keyboard to navigate through the page, ie: pagedown, space bar, pageup, home, end, arrow keys or the tab key. actual results: afte the page scrolls in response to step 3, "Find stopped" appears in the status bar. expected results: since i'm just moving around in the page --not trying to find something-- "Find stopped" shouldn't appear in the status bar. in fact, what makes this worse is that when i tab to a link, the link's url no longer appears in the status bar --that's certainly a regression. could this be related to bug 131256?
Assignee | ||
Comment 1•22 years ago
|
||
I think this only happens once type ahead find has been used at least once.
Assignee | ||
Comment 2•22 years ago
|
||
Assignee | ||
Comment 3•22 years ago
|
||
Comment on attachment 112816 [details] [diff] [review] CancelFind procedure shouldn't fire when there's nothing to cancel Kyle, could you try this patch out on Unix to make sure it seems to work right for you?
Attachment #112816 -
Flags: superreview?(Henry.Jia)
Attachment #112816 -
Flags: review?(kyle.yuan)
Assignee | ||
Updated•22 years ago
|
Attachment #112816 -
Flags: review?(kyle.yuan) → review?(brade)
Reporter | ||
Comment 4•22 years ago
|
||
another way to repro this: 1. load a page (eg, reload this page). 2. hover the pointer over a link. 3. click mouse over non-linked content. 4. look at status bar. results: "Find stopped" appears after clicking mouse (step 3).
Comment 5•22 years ago
|
||
I'm wondering if this is the same issue that's causing Mozilla to beep seemingly randomly when pages complete loading. I haven't been able to narrow down what circumstances this happens under, but every so often in the recent builds (I'm using 2003012308 at the moment), Mozilla beeps when the page is finished loading. Sometimes (but not always) when this happens, I see "find stopped" in the status bar. It's not reproducable even when loading the exact same page again. Same bug? Open a new one?
Comment 6•22 years ago
|
||
Comment on attachment 112816 [details] [diff] [review] CancelFind procedure shouldn't fire when there's nothing to cancel r=brade but it seems more optimal to reverse this line in nsTypeAheadFind::GetIsActive: + *aIsActive = !mTypeAheadBuffer.IsEmpty() || mLinksOnlyManuallySet; --> + *aIsActive = mLinksOnlyManuallySet || !mTypeAheadBuffer.IsEmpty();
Attachment #112816 -
Flags: review?(brade) → review+
Assignee | ||
Updated•22 years ago
|
Attachment #112816 -
Flags: superreview?(Henry.Jia) → superreview?(jst)
Comment 7•22 years ago
|
||
Comment on attachment 112816 [details] [diff] [review] CancelFind procedure shouldn't fire when there's nothing to cancel sr=jst
Attachment #112816 -
Flags: superreview?(jst) → superreview+
Assignee | ||
Updated•22 years ago
|
Attachment #112816 -
Flags: approval1.3b?
Comment 8•22 years ago
|
||
Comment on attachment 112816 [details] [diff] [review] CancelFind procedure shouldn't fire when there's nothing to cancel a=asa (on behalf of drivers) for checkin to 1.3beta.
Attachment #112816 -
Flags: approval1.3b? → approval1.3b+
Assignee | ||
Comment 9•22 years ago
|
||
checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 10•21 years ago
|
||
vrfy'd fixed with 2003.02.10 comm trunk bits on win2k, mac 10.2.3 and linux rh8.0.
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•