You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While writing new code I have encountered a bug in Postbox's implementation of Range.compareBoundaryPoints. This is exacerbated by the fact that it uses an old version of the Gecko JavaScript engine -- so old that Range.intersectsNode isn't supported.
I have exchanged some email with a Postbox dev(?), and I'm going to capture them here for reference.
(You can use my extension for this and stick the code in, say, markdown-here.js:markdownHere(). But be aware the Markdown Here code that it’s in that Github branch you mentioned doesn’t work with Postbox. I have some uncommitted changes here — like removing use of TreeWalker. Postbox uses older Gecko, etc.)
If you do the same repro scenario in Thunderbird (altering the rangeIntersectsNode code to force the fallback) it will return true.
It’s returning false in Postbox because both of these calls are returning 1:
…Where nodeRange is the the selected body. But that doesn’t make sense. Both of those returning 1 means that: “the start of the selection-range is after the end of the body-range and the end of the selection-range is after the start of the body-range”. (Well, the latter part of that statement is correct, but the former isn’t. And, sure enough, Thunderbird returns -1, 1.)
I wonder if that was the XUL document and XUL document body, and that is why it failed?
From me
At first I still couldn’t replicate your results, but then I moved code around and went back to the original rangeIntersectsNode. And… maybe I’ve figured out the problem? (Or a problem.)
TL;DR: In Postbox, node.ownerDocument.defaultView.Range.END_TO_START and node.ownerDocument.defaultView.Range.START_TO_END are undefined. However, Range.END_TO_START and Range.START_TO_END are fine.
Output from some logs that I’ll provide the code for below…
So… that seems weird? Like, node.ownerDocument.defaultView.Range exists but node.ownerDocument.defaultView.Range.START_TO_END doesn’t…? I can maybe work around this, but it’s going to be very hackish.
While writing new code I have encountered a bug in Postbox's implementation of
Range.compareBoundaryPoints
. This is exacerbated by the fact that it uses an old version of the Gecko JavaScript engine -- so old thatRange.intersectsNode
isn't supported.I have exchanged some email with a Postbox dev(?), and I'm going to capture them here for reference.
From me
I’m not sure if you got the links from my original email, but here’s the
Range.intersectsNode
fallback code in a StackOverflow answer I was referring to: https://stackoverflow.com/questions/1482832/how-to-get-all-elements-that-are-highlighted/1483487#1483487The reproduction scenario is like:
rangeIntersectsNode(document.defaultView.getSelection().getRangeAt(0), document.body)
false
.(You can use my extension for this and stick the code in, say,
markdown-here.js:markdownHere()
. But be aware the Markdown Here code that it’s in that Github branch you mentioned doesn’t work with Postbox. I have some uncommitted changes here — like removing use ofTreeWalker
. Postbox uses older Gecko, etc.)If you do the same repro scenario in Thunderbird (altering the
rangeIntersectsNode
code to force the fallback) it will returntrue
.It’s returning false in Postbox because both of these calls are returning
1
:…Where
nodeRange
is the the selectedbody
. But that doesn’t make sense. Both of those returning1
means that: “the start of the selection-range is after the end of the body-range and the end of the selection-range is after the start of the body-range”. (Well, the latter part of that statement is correct, but the former isn’t. And, sure enough, Thunderbird returns-1, 1
.)From Postbox
Can you try this:
rangeIntersectsNode(GetCurrentEditor().document.defaultView.getSelection().getRangeAt(0), GetCurrentEditor().document.body)
In Postbox, that returns true for me because:
range.compareBoundaryPoints(Range.END_TO_START, nodeRange) == -1
and
range.compareBoundaryPoints(Range.START_TO_END, nodeRange) == 1
I was calling that from chrome.
In your email you wrote:
rangeIntersectsNode(document.defaultView.getSelection().getRangeAt(0), document.body)
I wonder if that was the XUL document and XUL document body, and that is why it failed?
From me
At first I still couldn’t replicate your results, but then I moved code around and went back to the original
rangeIntersectsNode
. And… maybe I’ve figured out the problem? (Or a problem.)TL;DR: In Postbox,
node.ownerDocument.defaultView.Range.END_TO_START
andnode.ownerDocument.defaultView.Range.START_TO_END
are undefined. However,Range.END_TO_START
andRange.START_TO_END
are fine.Output from some logs that I’ll provide the code for below…
Postbox:
Earlybird:
Here’s the diff:
So… that seems weird? Like,
node.ownerDocument.defaultView.Range
exists butnode.ownerDocument.defaultView.Range.START_TO_END
doesn’t…? I can maybe work around this, but it’s going to be very hackish.Am I missing something?
From Postbox
I think this is https://bugzilla.mozilla.org/show_bug.cgi?id=665279
We don't have that fix in Postbox yet.
See mozilla/addon-sdk@3ef0d9b for a way that bug # 665279 was worked around before it was fixed.
But that might be more hackish that the hack you have in mind.
Let me know what you come up with.
ps: At first I thought it was because the object wasn't a XPCNativeWrapper (XrayWrapper), but I don't think that's it:
[object XrayWrapper [object Window]]
vs
[object Window]
But in case you're curious:
https://developer.mozilla.org/en-US/docs/XPCNativeWrapper
https://developer.mozilla.org/en-US/docs/Safely_accessing_content_DOM_from_chrome
The text was updated successfully, but these errors were encountered: