Comment 150 for bug 584632

(In reply to Jorg K from comment #60)
> The more conservative approach would be not to change the selection
> behaviour but to maintain/re-establish the correct "type in state" after the
> click. That is what IE does: The DIV is selected, but typing continues in
> the "correct" font, see comment #54. Would you prefer this approach?

No. TypeInState can only remember the properties set while the selection has not changed, so it is never the right fix for bugs that occur when you move the selection around in the document.

> One could argue that clicking 10cm or 4" away from the text to the right
> should not select the text. On the other hand, if no <br> follows, then you
> can click far to the right and the text is still selected. Also for text in
> <p></p> you can click far to the right and still select the text. Note that
> links are not followed, even though the text is selected. That's the last
> example.

Sorry, I'm not really sure what you mean here.

> Personally I would fire any web designer who creates websites for one
> browser alone and who creates special code for somewhat far-fetched cases of
> clicking a text.

Or here. :-)

(In reply to Jorg K from comment #61)
> It's not going past static FrameTarget GetSelectionClosestFrameForLine ()
> http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#3540
> ... nor static FrameTarget GetSelectionClosestFrameForBlock nor static
> FrameTarget GetSelectionClosestFrame.
>
> Also, very little processing in nsFrame::HandlePress. As I said before,
> leaving there at line 2819:
> http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#2819

Hmm, I wasn't guessing in comment 55, I actually ran this under the debugger, so I'm pretty sure you're doing something wrong. Not sure what exactly...

> These functions fire when you hover over or click into the URL field (or the
> search box), but NOT the rendered HTML.

Hmm, maybe that's because you're attached to the wrong process? Does the active tab have an underline on its title? If yes, you're in e10s mode where we run the rendered content in a separate process. If this is what's happening, try either attaching the debugger to the content process, or open a new non-e10s window and load the test case there.

> I'm not afraid of a large C++ code base, but I need a place to start. As I
> said, five minutes of your time can possibly save me five hours or five days
> of "reverse engineering".

I'm trying to help, comment 55 should give you everything you need to get started.

(In reply to Jorg K from comment #62)
> As I said before, GetSelectionClosestFrameForLine is not called. The
> following statements I placed into the corresponding functions in
> nsFrame.cpp are not reached:
> printf ("=== in GetSelectionClosestFrameForLine\n");
> printf ("=== in GetSelectionClosestFrameForBlock\n");
> printf ("=== in GetSelectionClosestFrame\n");
> printf ("=== in nsIFrame::GetContentOffsetsFromPoint\n");

This cannot possibly be true, I guarantee that. It's either you being attached to the wrong process or something else...

> Further suggestions appreciated. I'd really like to find the code that
> identifies the element under the cursor.

Again, nsIFrame::GetContentOffsetsFromPoint().

> Also, is there a way to dump
> out/print these data structures? How do you "print" an nsIFrame or an
> nsBlockFrame?

Yes! You can call nsIFrame::DumpFrameTree() on any frame in the frame tree to get a full dump of the frame tree (you can look up the specific frame you have by looking for its address in the frametree dump.) If you're under gdb or lldb, there is a helper command called ft, which dumps the frametree, otherwise you can just call that function under the debugger as |myFrame->DumpFrameTree()|.

Also if you have a debug build, you can use the Layout Debugger under the Tools menu which gives you a GUI which dumps things such as the frame tree, the content (DOM) tree, etc.