Open Bug 1070492 Opened 11 years ago Updated 1 year ago

Ctrl+F or 'Edit → Find' do not start 'Search' in HTML Source View

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Version:
SeaMonkey 2.29 Branch
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(seamonkey2.32 affected)

Status:
ASSIGNED
Tracking Flags:
Tracking Status
seamonkey2.32 --- affected

People

(Reporter: Dmitry.Semionin, Assigned: njsg)

References

Details

Attachments

(1 file, 2 obsolete files)

1070492-composer-findbar-v3
2.67 KB, patch
njsg
: feedback?
iannbugzilla
frg
: feedback+
Details | Diff | Splinter Review
User Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 20140917194002 Steps to reproduce: Prior to version 2.29, pressing Ctrl+F while viewing the "<HTML> source" tab in Composer opened a "Find and Replace" window which could be used for searching through the source code of the document. In version 2.26 and below the contents of the "Edit" section of the main menu have the "Find..." item for the "Normal" tab which is bound to Ctrl+F, but for the "<HTML> Source" only "Find and Replace..." is present, yet bound to the same hotkey. So, in any of those two modes i could use the common hotkey to access the search function. Actual results: In version 2.29 the search function has been revamped and a Firefox style search panel had been added replacing the old dialog window. In the "Normal" tab this panel appears above the document upon pressing Ctrl+F. However in the "<HTML> Source" tab this hotkey does absolutely nothing, yet in the "Edit" section of the menu there's the "Find..." item bound to this hotkey, while "Find and Replace..." is linked to a different hotkey. Therefore, i can't use the typical hotkey to access the function previously linked to it. Expected results: The expected result is to have Ctrl+F work on the "<HTML> Source" tab too, either by displaying the new fancy search panel or by showing the Find and Replace dialog window like it used to work before.
Seems to be an issue. Note that Ctrl+F is Find. And Ctrl+H is Find & Replace (Without looking back, I gather this is a recent change.) Note that on first load, Ctrl+F, Ctrl+H work in the Normal tab, though switching through tabs, you will find that Find then fails everywhere. > Error: element is null > Source File: chrome://editor/content/editor.js > Line: 2773 > Error: An error occurred updating the cmd_updateStructToolbar command: [Exception... "[JavaScript Error: "element is null" > {file: "chrome://editor/content/editor.js" line: 2773}]'[JavaScript Error: "element is null" {file: "chrome://editor/content/editor.js" line: 2773}]' > when calling method: [nsIControllerCommand::isCommandEnabled]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" > location: "JS frame :: chrome://global/content/globalOverlay.js :: goUpdateCommand :: line 78" data: yes] > Source File: chrome://global/content/globalOverlay.js > Line: 84 > Error: An error occurred executing the cmd_NormalMode command: [Exception... "[JavaScript Error: "element is null" > {file: "chrome://editor/content/editor.js" line: 2773}]'[JavaScript Error: "element is null" {file: "chrome://editor/content/editor.js" line: 2773}]' > when calling method: [nsIControllerCommand::doCommand]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" > location: "JS frame :: chrome://global/content/globalOverlay.js :: goDoCommand :: line 94" data: yes] > Source File: chrome://global/content/globalOverlay.js > Line: 98
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reproducible with German SeaMonkey 2.32.1 Build 20150204202218 on German WIN7 64bit This problem is not limited to Vista, can someone please modify picker? At least with WIN7 problem is not limited to keyboard shortcut, also menu 'Edit ► Find' will not bring up the Find-Toolbar.
status-seamonkey2.32: --- → affected
I can reproduce this for Mac (2.29 up to trunk) and Linux (trunk) as well. Also, this is a major usability defect, despite the workaround.
Severity: normal → major
OS: Windows Vista → All
Hardware: x86_64 → All
Version: SeaMonkey 2.29 Branch → Trunk
Attached patch attach findbar to active editor (obsolete) — — Splinter Review
This patch moves the findbar outside of the editor deck and reattaches itto the correct editor element when switching tabs.
Assignee: nobody → mnyromyr
Attachment #8563813 - Flags: review?(neil)
Comment on attachment 8563813 [details] [diff] [review] attach findbar to active editor The findbar gets confused when you switch mode; I think this is because you are trying to fake it out by clearing the browser property. Instead you should ignore the attribute and set the browser property.
Attachment #8563813 - Flags: review?(neil) → review-
The findbar member .browser covers internalities like initializing the internal _browser field, if necessary, or attaching event handlers. Unfortunately, the findbar code itself doesn't use always .browser but ._browser sometimes. This patch enforces the internal reinit without copying internal findbar actions.
Attachment #8563813 - Attachment is obsolete: true
Attachment #8565681 - Flags: review?(neil)
Comment on attachment 8565681 [details] [diff] [review] attach findbar to active editor, v2 >+ findbar.setAttribute("browserid", (mode == kDisplayModeSource) ? "content-source" : "content-frame"); >+ findbar.browser = null; >+ findbar.browser = findbar.browser; // enforce findbar reinit So why not just set findbar.browser to the appropriate element directly? Nit: non-breaking spaces in code. And I have no idea what happened to the colon.
Version due to user story
Version: Trunk → SeaMonkey 2.29 Branch
Comment on attachment 8565681 [details] [diff] [review] attach findbar to active editor, v2 Ah, I know, you've got non-breaking spaces. Anyway my question still stands.
Attachment #8565681 - Flags: review?(neil) → review-
Same issue as "Bug 1065836 - Impossible to bring up find bar in source view"?
See Also: → 1065836
Summary: Composer doesn't handle Ctrl+F when working with the document's HTML code → Ctrl+F or 'Edit → Find' do not start 'Search' in HTML Source View
Saw this bug in November 2014 running SeaMonkey 2.3 under Mac OS 10.9. Still seeing it in July 2016 running SeaMonkey 2.4, Build identifier 20160120191716, under Mac OS 10.11.6. "Find", "Find Again" and "Find Previous" all fail every time when looking at the HTML source of a page being edited in Composer. "Find and Replace" either from menu or by key command is a reliable workaround, but those other three commands really should do something.
2018-06-26: As of SeaMonkey 2.49.3 running in macOS 10.12.6 (Sierra), this bug is still not fixed. The key command (Command-F) will not work under any circumstances in <html>Source view, and the normal "Find" dialog will not appear. I can get the "Find and Replace" dialog to appear using the "Edit:Find and Replace..." menu item, but ONLY after first placing the cursor somewhere in the <html>Source view page content. If I just open a Composer page in the <html>Source view and attempt to use any Find function, no dialog appears. Before I use the "Edit:Find and Replace..." menu item, there is no key command shown for the "Edit:Find..." menu item. After I use the "Edit:Find and Replace..." menu item, then the Command-F key command is displayed in the Edit menu. However, the same key command is also displayed for the "Edit:Find and Replace..." menu item. That's right–––the same key command is shown for two different menu items...and it doesn't work in either case. Pressing the Command-F keystroke combination temporarily highlights the Edit menu item in the menu bar, but neither the "Find" dialog nor the "Find and Replace" dialog appear. The key command is completely broken.
As of this writing, this bug has only one vote...mine. I would encourage all those who consider this bug a nuisance to vote for it. It's a good idea to vote for any bug that you'd like to get fixed.
(In reply to Vito Tuxedo from comment #16) > It's a good idea to vote for any bug that you'd like to get fixed. No, voting will not speed up any bug fixing process. The problem is the lack of developer manpower.
Assignee: mnyromyr → nobody
  • Comment 15: the cursor/focus thing is bug 687482
  • Comment 14: a curiosity/detail: at least currently (2.53) the commands do work, but in the other editor element, the one to which the findbar is attached, so results are not visible. For example, if you try ctrl+F, then after you switch back from the Source view, the findbar will be open if it wasn't before. If the findbar was already open and has some expression in its text field, you can also see the result (selected text) from "Find Next" when you switch back from the Source view, if you haven't changed the document source.

Updated patch on top of 2.53.18.2/2.53.19b1pre.

Other than the different file paths for editor.js and editor.xul:

  • I tried to do as suggested in Comment 8 and change findbar.browser directly

  • I also tried to make the findbar.browser change happen only when the mode change is between the Source view and a non-Source view. Or is this overkill?

Assignee: nobody → nunojsg
Attachment #8565681 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #9404212 - Flags: feedback?(iannbugzilla)
Attachment #9404212 - Flags: feedback?(frgrahl)

Comment on attachment 9404212 [details] [diff] [review]
1070492-composer-findbar-v3

So far so good. Find bar shows fine but as discussed in irc we now seem to have 2 different find boxes. which can have different content for source view. Not bad but confusing. Leving it to IanN if we should put this in as is as a start ond try to do a follow up (which might take its time again)

Attachment #9404212 - Flags: feedback?(frgrahl) → feedback+

(In reply to Frank-Rainer Grahl (:frg) from comment #23)

Comment on attachment 9404212 [details] [diff] [review]
1070492-composer-findbar-v3

So far so good. Find bar shows fine but as discussed in irc we now seem to have 2 different find boxes. which can have different content for source view. Not bad but confusing. Leving it to IanN if we should put this in as is as a start ond try to do a follow up (which might take its time again)

I'm not sure what "So far so good" means here. I'm using 2.53.20, and neither ctrl-F nor selecting "Find" from the Edit menu brings up a find bar in the <HTML> source tab. The ctrl-H/Find and replace workaround works to a certain extent, but there's still the problem that it doesn't work if you having put the cursor into the editing window. Further, if you switch to, e.g., the Preview tab and then back to the <HTML> source tab, you have to re-put the cursor into the editing area. Seems pretty "bad" to me.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: