Change nsIDOMHTMLEmbedElement access method in suite/browser/nsTypeAheadFind.js

RESOLVED FIXED in seamonkey2.58

Status

enhancement
RESOLVED FIXED
2 years ago
Last year

People

(Reporter: qdot, Assigned: frg)

Tracking

(Blocks 1 bug)

Trunk
seamonkey2.58
Dependency tree / graph

SeaMonkey Tracking Flags

(seamonkey2.57esr fixed, seamonkey2.58 fixed)

Details

Attachments

(1 attachment)

In bug 1387184, we've removed the nsIDOMHTMLEmbedElement interface. This will be need to changed in comm-central suite/browser/nsTypeAheadFind.js.
Assignee

Comment 1

2 years ago
> This will be need to changed in comm-central suite/browser/nsTypeAheadFind.js.

Any suggestions for a replacement?
Flags: needinfo?(kyle)
I think 

document.commandDispatcher.focusedElement.tagname.toLowerCase() === "embed" 

might do it? ni?'ing bz 'cause I'm not sure that's the best way though.
Flags: needinfo?(kyle) → needinfo?(bzbarsky)
Er, actually

document.commandDispatcher.focusedElement instanceof windows.content.HTMLEmbedElement

may also work and get rid of a nasty string compare. But I'll wait for bz's input.
So using instanceof HTMLEmbedElement is a bit fragile because who knows when we'll break it working across globals.

I think 

  element.localName === "embed" && element.namespaceURI === "http://www.w3.org/1999/xhtml"

is the sanest option here.
Flags: needinfo?(bzbarsky)
Assignee

Comment 5

2 years ago
Thanks guys. Really appreciate the help. A bit overwhelming right now with all the changes :)
Assignee

Updated

2 years ago
Product: Thunderbird → SeaMonkey
Version: unspecified → Trunk
Assignee

Updated

2 years ago
Duplicate of this bug: 1390467

Comment 7

2 years ago
re bug 1390467

In 2.54a1 builds prior to 20170813013143/windows and 20170813003001/linux when preferences-advanced-find as you type-show the find toolbar... (accessibility.typeaheadfind.usefindbar) was unchecked find as you type worked and the search target was shown on the status bar. In the latest builds unchecking this option breaks FAYT completely. If it is indeed caused by this change, it is not good at all: the find toolbar, at least the way it works now - popping up on top and shifting the page down, causes nothing but motion sickness, eye strain and annoyance - an very poor design choice, document should never move unless explicitly requested by user. Unless the find toolbar is redesigned to something more user-friendly the status bar FAYT should be maintained.
Assignee

Comment 8

2 years ago
>  the status bar FAYT should be maintained.

Patience. No one wants to remove anything. A fix has been proposed and just needs to be implemented.
Assignee

Updated

2 years ago
Flags: needinfo?(frgrahl)
Assignee

Updated

Last year
Assignee: nobody → frgrahl
Status: NEW → ASSIGNED
Flags: needinfo?(frgrahl)
Assignee

Comment 9

Last year
[Approval Request Comment]
Regression caused by (bug #): Bug 1387184
User impact if declined: broken find
Testing completed (on m-c, etc.): c-b
Risk to taking this patch (and alternatives if risky): trivial
String changes made by this patch: --
Attachment #8966027 - Flags: review?(iann_bugzilla)
Attachment #8966027 - Flags: approval-comm-beta?

Comment 10

Last year
Comment on attachment 8966027 [details] [diff] [review]
1389622-HTMLEmbedElement.patch

LGTM r/a=me
Attachment #8966027 - Flags: review?(iann_bugzilla)
Attachment #8966027 - Flags: review+
Attachment #8966027 - Flags: approval-comm-beta?
Attachment #8966027 - Flags: approval-comm-beta+

Comment 11

Last year
Pushed by frgrahl@gmx.net:
https://hg.mozilla.org/comm-central/rev/6e4f454d00c7
Remove usage of nsIDOMHTMLEmbedElement in SeaMonkey. r=IanN
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.