I've done a little debugging.
On every mouse move event we get this:
>>> Entering PresShell::HandleEvent, frame=06EA9488
PresShell::HandleEvent calling nsLayoutUtils::GetEventCoordinatesRelativeTo
PresShell::HandleEvent calling FindFrameTargetedByInputEvent
PresShell::HandleEvent assigning frame = target, frame=1DD7F010
=== about to call HandlePositionedEvent, frame=1DD7F010
=== in PresShell::HandlePositionedEvent,
mCurrentEventContent/Frame=0D066380/1DD7F010
<<< Leaving PresShell::HandleEvent right after HandlePositionedEvent
(BTW, none of the frame numbers change when you move the cursor around. Unless
you reload the page, they are always the same numbers).
Surely somewhere in there it works out what is under the cursor, since
when the cursor is over a link, things happen (cursor changes, link
target is displayed). Sadly, I haven't yet found that code.
If the button is clicked and released, we additionally get calls to HandlePress
and HandleRelease
>>> Entering PresShell::HandleEvent, frame=06EA9488
PresShell::HandleEvent calling nsLayoutUtils::GetEventCoordinatesRelativeTo
PresShell::HandleEvent calling FindFrameTargetedByInputEvent
PresShell::HandleEvent assigning frame = target, frame=1DD7F010
=== about to call HandlePositionedEvent, frame=1DD7F010
=== in PresShell::HandlePositionedEvent,
mCurrentEventContent/Frame=0D066380/1DD7F010
=== in nsFrame::HandlePress
<<< Leaving PresShell::HandleEvent right after HandlePositionedEvent
>>> Entering PresShell::HandleEvent, frame=06EA9488
PresShell::HandleEvent calling nsLayoutUtils::GetEventCoordinatesRelativeTo
PresShell::HandleEvent calling FindFrameTargetedByInputEvent
PresShell::HandleEvent assigning frame = target, frame=1DD7F010
=== about to call HandlePositionedEvent, frame=1DD7F010
=== in PresShell::HandlePositionedEvent,
mCurrentEventContent/Frame=0D066380/1DD7F010
=== in nsFrame::HandleRelease
<<< Leaving PresShell::HandleEvent right after HandlePositionedEvent
Here is the stack from the HandlePress call:
nsFrame::HandlePress(<args>) Line 2776 C++
nsFrame::HandleEvent(<args>) Line 2562 C++
nsPresShellEventCB::HandleEvent(<args>) Line 507 C++
mozilla::EventTargetChainItem::HandleEventTargetChain(<args>) Line 346 C++
mozilla::EventDispatcher::Dispatch(<args>) Line 634 C++
PresShell::DispatchEventToDOM(<args>) Line 8168 C++
PresShell::HandleEventInternal(<args>) Line 8064 C++
PresShell::HandlePositionedEvent(<args>) Line 7896 C++
PresShell::HandleEvent(<args>) Line 7689 C++
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");
So the idea of discarding the BRFrame in GetSelectionClosestFrameForLine
is perhaps not viable.
Further suggestions appreciated. I'd really like to find the code that
identifies the element under the cursor. Also, is there a way to dump
out/print these data structures? How do you "print" an nsIFrame or an
nsBlockFrame?
Also, please answer the first question in comment #60 which suggested to
not change the selected frame but to tweak the "type in state" like IE
does. IE selects the DIV, but typing happens in the font of the
preceding text element in the line. That may be an alternate way to fix
the "lost font" problem that doesn't change existing selection
behaviour.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
composer changes font mid email
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunderbird/+bug/584632/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
