Open Bug 505196 Opened 15 years ago Updated 3 years ago

Search dialog find in page doesn't remember wrap state after restart

Categories

(SeaMonkey :: Find In Page, defect)

Product:
SeaMonkey
Component:
Find In Page
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

People

(Reporter: prof, Unassigned)

References

Details

(Whiteboard: [Broken as designed?])

Attachments

(1 file)

Extension that remembers the find dialog settings
4.84 KB, application/x-xpinstall
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.9.1.1pre) Gecko/20090717 SeaMonkey/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.9.1.1pre) Gecko/20090717 SeaMonkey/2.0b1

When changing the options to (not) match the case or to (not) wrap around in the search dialog to find text in a page these options are not being remembered for the next start of Seamonkey.
Especially when the wrap is not appreciated the continuous re-enabling after each start of the app is extremely annoying.

Reproducible: Always

Steps to Reproduce:
1. open the search for finding text in a webpage and enable matching the case or disable wrap in the find in page dialog
2. perform a search
3. restart app and open search dialog again
Actual Results:  
settings are forgotten.

Expected Results:  
settings of the dialog should be remembered.
This appears to be deliberate. See Bug 387756 Comment 4:

> Created an attachment (id=272148)
> Also set default to wrap

> This makes wrap the default but it remembers until restart if you turn it off.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Summary: Search dialog find in page doesn't remember checkbox states / search dialogue forgets checkbox states after restart → Search dialog find in page doesn't remember wrap state after restart
Whiteboard: [Broken as designed?]
Problem also reported in MozillaZine:
<http://forums.mozillazine.org/viewtopic.php?f=40&t=1381105&start=0>
Unfortunately toolkit (i.e. Firefox) wants wrap to be the default. Ideally the find service itself could save the wrap state across a restart but that would be a 1.9.2 toolkit bug and so could not be fixed for SeaMonkey 2.0, but alternatively someone might be able to write an extension to emulate this.

(In reply to comment #0)
> Especially when the wrap is not appreciated the continuous re-enabling after
> each start of the app is extremely annoying.
You would have hated the previous Firefox behaviour which was to re-enable it each time you opened the find dialog!
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
I've recognized the new dialog which warns when one has searched through the entire document for one time. That's a great improvement compared to the alpha-versions of SM2. With that thing added in beta1 one can live with that until there's an SM based on toolkit 1.9.2 I guess...
Resolution: INVALID → WONTFIX
I could port the Elephant Find Wrap extension[1] which overrides |fillDialog()| to SeaMonkey I guess. But shouldn't this be done as part of SeaMonkey instead?

Would a patch that overrrides the fillDialog() function in the toolkit finddialog.js be acceptable? Or since the find *dialog* is "Not Part of the Default Firefox Build", I guess we could fix it more directly there.

[1] Uses a pref to remember the wrap state between sessions.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to comment #5)
> Would a patch that overrrides the fillDialog() function in the toolkit
> finddialog.js be acceptable? Or since the find *dialog* is "Not Part of the
> Default Firefox Build", I guess we could fix it more directly there.
We don't need to override the find dialog; that's why bug 387756 exists.
Status: REOPENED → NEW
Version: unspecified → Trunk
Bug 387756 should never have been fixed as described.  When I say not to wrap, I want it to stay that way even after I terminate SeaMonkey and then restart it.  What bug 387756 did was to break something that worked.
(In reply to comment #7)
> Bug 387756 should never have been fixed as described.  When I say not to wrap,
> I want it to stay that way even after I terminate SeaMonkey and then restart
> it.  What bug 387756 did was to break something that worked.
Bug 387756 was about remembering the wrap state between finds. I don't think SeaMonkey has ever remembered the wrap state between launches.
Severity: normal → enhancement
Keywords: regression
(In reply to comment #8)
> Bug 387756 was about remembering the wrap state between finds. I don't think
> SeaMonkey has ever remembered the wrap state between launches.

If this is the case, then at least the default was changed :-S

btw: SM2.0 final still has issues to not mention the wrap-around, but just does it very often.
I just now confirmed that, if SeaMonkey 1.1.18 had a default for this, it was NOT to wrap.  Defaulting to wrapped finds is a @!#??!!* annoyance.  Wrapping suppresses any alert that I have reached the end of the page without finding any further instances of the search string.
SeaMonkey 1.1.18 did indeed have a default for Find in Page.  It was NOT to wrap.  Thus, the current state -- defaulting to wrap -- represents a regression.  

This bug report is not an RFE.  It reports a discrepancy.  Importance changed from Enhancement to Normal.
Severity: enhancement → normal
Sorry but it is an enhancement relative to the toolkit code on which we are now based on.
Severity: normal → enhancement
To the end-users, this is a regression bug.  End-users don't really care how such a bug was introduced.  If this is a "feature" of a toolkit, then the toolkit is in error.
I also find this wrap by default annoying as well. Please do make it an option to users.
Blocks: 609787
Per the mozilla.dev.extensions newsgroup thread with subject "Extension Wanted -- Remember Wrap State of Search Dialogue" (started 1 September 2010), an extension was created as a work-around for this bug by Neil Rashbrook.  However, Rashbrook does not plan to formalize the extension for Mozdev or addons.mozilla.org.  Furthermore, the current extension requires a minor tweak to prevent remembering the search string.
Just in case anyone finds it useful.
> No, I'm not planning on updating it. It will only break if someone 
> changes nsIFindService.idl or rewrites component registration again.
These should be very rare. Can we take the core of this code into the seamonkey source tree?
Re comment #17:  

The attachment is not an .xpi file.  Do I merely change the .cgi file extension to .xpi?  Or do I have to do something else?  

Is this is based on Rashbrook's extension (comment #15)?  Rashbrook's extension seems to have a bug.  Occasionally, the Wrap checkbox gets checked.  That seems to happen after I have done a search.  When this happens, the extensions.find.search_string preference variable contains the last search string I input.  I have seen this with extensions.find.search_string initialized via user.js to either a null string or to a 1-character blank string.
Comment on attachment 497175 [details]
Extension that remembers the find dialog settings

Yes, this is my extension, but I checked the "patch" checkbox by mistake.
Attachment #497175 - Attachment is patch: false
Attachment #497175 - Attachment mime type: text/plain → application/x-xpinstall
Another problem that I am seeing is that a search for a string definitely known to exist will sometimes fail while using the dialogue popup.  After dismissing the popup, F3 successfully finds the string.  

It is a sporadic problem.I don't know if this is caused by the extension or is a basic problem with the vanilla Find in Page.  I will run for a while with the extension disabled to see if it happens then.
I think you might find that what you are seeing is the result of the search initial position not being set to the top of the page when a new page loads.  That is why it appears to be sporadic.  If you click somewhere at the top of the page before your search then you will probably find that it works better - but you shouldn't need to do that, of course, because the position should always be reset to the top of the page when a page loads.

But maybe all of this just highlights a serious lack of quality control for this product?  How can such glaring faults make it out the door in the first place?  Surely somebody must have responsibility for at least testing every single major feature before a release?  Is there anybody with such a responsibility?  And if so can they please explain why simple search is broken, and password memory and lots of other important things are also seriously broken.  It is so bad I have had to revert to 1.1.18.
(In reply to comment #17)
> Created attachment 497175 [details]
> Extension that remembers the find dialog settings
> 
> Just in case anyone finds it useful.

Now on AMO: https://addons.mozilla.org/en-US/seamonkey/addon/find-preferences/

It failed to meet the criteria for full review because it hasn't enough users.
Thanks a lot dude. :-)
Is there a reason why this is not being implemented into SM directly?

btw: the download-counter said 6, I downloaded it and the download-counter still said 6. :-o
> Is there a reason why this is not being implemented into SM directly?
Somebody needs to volunteer to add this to SM directly.

> btw: the download-counter said 6, I downloaded it and the download-counter still said 6. :-o
AMO is full of bugs unfortuantely.
Ah ok, I wasn't aware that this would be more "painful" than creating it as an extension, I'm not familiar with the process.

I noticed the extension even remembers the last searched word. If this would land into Seamonkey it should maybe be considered to not store this field. Although I'm not 100% sure about that.
Note that you can use user.js to reset the settings to your favourite values on startup, instead of simply saving them.
In SeaMonkey 2.1RC1, the Find dialogue is now a toolbar instead of a popup.  The toolbar has no options to turn off wrapped searches.  There is no longer an option not to wrap searches.  

This is a regression.  There is no workaround.  Importance changed from RFE to Major.
Severity: enhancement → major
(In reply to comment #29)
> In SeaMonkey 2.1RC1, the Find dialogue is now a toolbar instead of a popup. 
> The toolbar has no options to turn off wrapped searches.  There is no longer
> an option not to wrap searches.
You can turn off the find bar.
browser.findbar.enabled - turns off the find bar for Edit menu (or Ctrl+F)
accessibility.typeaheadfind.usefindbar - turns off the find bar for find as you type (this one also exposed in preferences - advanced - find as you type).
One can count that as a workaround (disabling the findbar), but I can confirm that the findbar in SM2.1 lacks the option to disable wrap-around. (interestingly enough it has the case-checkbox and even that wrap-warning though, but nothing to do anything against it ;-))
The implementation of bug #171237 fails to work when the Find popup is used in place of the Find tool bar as suggested in comment #30.
(In reply to David E. Ross from comment #32)
> The implementation of bug #171237 fails to work when the Find popup is used
> in place of the Find tool bar as suggested in comment #30.
Bug #171237 only affects typeaheadfind (both versions), not the dialog.

(You could try filing a bug against the dialog, but I don't know whether you'll have any joy, given that Firefox doesn't use that dialog...)
Re comment #29:  The lack of a Wrap/NoWrap option on the Find toolbar is bug #618499.
So this bug should now be depended on bug #618499.
This bug is about the dialog, not the find bar. I don't think the find bar shares much code* with the dialog, so changes to one won't affect the other. Even if the find bar does get the option to disable wrap state, it would probably need its own code to remember it after restart.

*About the only code it shares is the code internal to the window.find function.
(In reply to neil@parkwaycc.co.uk from comment #36)
Actually this bug was submitted before forking search to bar and dialog branches (in bug #97023). And then the dialog became deprecated and replaced by the bar (at least for most end users).

I'd suggest to retarget this bug to the search bar (as a successor) instead of the dialog and resolve it here. But if You mind a chance to work with the dialog here we could file a same bug about the bar.
Re comment #37:  

I very much disagree.  There are now too many "bars", each of which reduces the height of the rendered Web page by pushing the top of the page down (see bug #658188).  For that reason, I have set browser.findbar.enabled to "False".  

This needs to be fixed for BOTH the Find bar and the Find dialogue popup.
No longer blocks: 609787
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: