User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20150305021524 Steps to reproduce: Steps: 1: Go in Preferences in Firefox in Yoshmite OS (about:preferences) 2: Use three finger tap in any word Firefox, General, Tabs.(bold written) Actual results: When I use three finger single tap in "preferences" in "firefox" browser it doesn't shows the meaning of all the word, especially bold written words like "General", "Firefox", “Tabs". Expected results: It should have showed the details about all the words on which three finger tap is used.

We don't yet fully support the lookup gesture, which is bug 687026. But I find that using a double three-finger tap on a word in a "normal" web page works just fine in Firefox 36.0.1 in OS X 10.10.2. (Though it's true that a single three-finger tap doesn't work there, as it does in Safari.) But this bug is about the Preferences pane, and I can confirm your report. Oddly, it's also not possible to select text in the Preferences pane, and I expect that's the real bug -- the reason why a double three-finger tap doesn't work there.

> Oddly, it's also not possible to select text in the Preferences > pane, and I expect that's the real bug -- the reason why a double > three-finger tap doesn't work there. Oops, that's wrong. You can't select text in Safari's Preferences panel, either, but the three-finger tap works fine there. So this bug covers one aspect of providing full support for the lookup gesture. I'll dup it to that bug and write a comment there.

As I commented in bug 687026, the gesture has been working fine in general cases. The screenshot shows that this bug is about the highlight being broken in our preferences page, which is a different problem. Actually, I think this problem could also happen when we have web page with something like: <p>hello</p><p>world</p> Hence the real problem is, we do not add break on the boundary of non-inline element to separate words.

I guess there are two ways to solve this problem: the first is inserting a new line for every boundary of non-line-participant frames, the second is stop the flat content at those boundaries. I've been trying the first approach, but haven't got any result. I wonder which way is better. I suspect that inserting new lines for boundary might break some invariant, because the characters don't relate to any content node, but I'm not sure. masayuki, do you have any suggestion?

Doesn't it work with inserting a white-space instead of a new line? A line break has a meaning in some widgets. E.g., on Linux, when we receive "retrieve-surrounding" signal, we return text of current paragraph which is between previous line break and next line break. So, inserting new line between elements may break such code. Anyway, ideally, we should insert new lines in ContentEventHandler at finding some elements like <p>, <blockquote> etc. (shouldn't insert after phrase elements like <i>, <b>, <a>, etc)

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #6) > Doesn't it work with inserting a white-space instead of a new line? A line > break has a meaning in some widgets. E.g., on Linux, when we receive > "retrieve-surrounding" signal, we return text of current paragraph which is > between previous line break and next line break. So, inserting new line > between elements may break such code. > > Anyway, ideally, we should insert new lines in ContentEventHandler at > finding some elements like <p>, <blockquote> etc. (shouldn't insert after > phrase elements like <i>, <b>, <a>, etc) Hmm, non-line-participant frames mean almost exactly what you said. I just wanted to confirm whether there is any invariant that characters we returned should have related content node.

It seems to me that it would need non-trivial work to fix this bug. If we want to insert newlines around some elements, we need to change both direction of conversion between DOM range and flat text offset. Also, we may need a content iterator which visits a node for both start tag and end tag. And we will need to consider the relationship between offset in DOM range and the fake content we generate.

I see very odd behavior in preferences with this - I get a highlight with an odd string, and a Not Found dictionary popup.

I have 48. 3 finger tap to open dictionary is broken for me.