The default bug view has changed. See this FAQ.

nsIEditor.removeEditActionListener exception in this case when unhighlighting after changing source of iframe

RESOLVED FIXED in mozilla1.9.3a1

Status

()

Toolkit
Find Toolbar
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: graememcc)

Tracking

({regression, testcase})

Trunk
mozilla1.9.3a1
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
Created attachment 380009 [details]
testcase

See testcase, to reproduce:
- Open testcase, press ctrl-f
- Search for the letter 'e' and click on 'Highlight all'
- In the testcase, press the 'change location of iframe' button
- Click on 'Highlight all'
- Click again on 'Highlight all'

After that, I see this error in the error console:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIEditor.removeEditActionListener]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/bindings/findbar.xml :: _unhookListenersAtIndex :: line 499"  data: no]

And I think this can also lead somehow to this error (although I have no precise way to reproduce that one):
Error: uncaught exception: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIEditor.document]"  nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: chrome://global/content/bindings/findbar.xml :: _highlightDoc :: line 981"  data: no]
Usually, when this error starts happening, the whole unhighlighting business seems to go wrong partly.
(Assignee)

Comment 1

8 years ago
Created attachment 392084 [details] [diff] [review]
Patch v1

Part of the problem here is the code in browser.js that reverts the state of the highlight button on an onLocationChange event, in the testcase caused by the changing of the iframe src.

However, the real problem is that the highlight code attaches listeners multiple times if there are multiple matches in the editor. The testcase is analagous to this, because when the onLocationChange causes the button state to be cleared, the findbar internal state isn't cleared - we're already hooked up as a listener from the first highlighting, so when we highlight again we are adding another set of listeners.

The editors themselves cope with this just fine - they do the right thing in the case of duplicate entries. However, at the final unhighlighting, we are calling removeEditActionListener twice on the same editor. The first call succeeds, and then the second time we have already been removed, causing the exception.

Annoyingly I see that I was far-sighted enough when I wrote the code for the listeners within the findbar - they can already cope with multiple matches in one editor. It's just the highlighting code that gets it wrong.

The patch fixes that and extends (and tidies up) the 451540 test to show that everything works correctly.
Assignee: nobody → graememcc_firefox
Status: NEW → ASSIGNED
Attachment #392084 - Flags: review?(mano)
Comment on attachment 392084 [details] [diff] [review]
Patch v1

r=mano
Attachment #392084 - Flags: review?(mano) → review+
(Assignee)

Comment 3

8 years ago
http://hg.mozilla.org/mozilla-central/rev/51e562b1032e
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
OS: Windows XP → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
You need to log in before you can comment on or make changes to this bug.