desktop-packages team mailing list archive

[Ehsan-mozilla <584632@xxxxxxxxxxxxxxxxxx>]

(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.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/584632

Title:
  composer changes font mid email

Status in Mozilla Thunderbird Mail and News:
  Confirmed
Status in thunderbird package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: thunderbird

  As I'm typing my emails in Thunderbird, I can see what appears to be a
  font size change on screen, normally in the second line of text. The
  second line appear smaller than the first. It's barely perceptible, so
  half them time I think I am imagining it.

  Well, I've started Bccing to myself to check, and the emails I am
  receiving from myself are not only a different size, they're also a
  different font. Composer starts in some default serif, and by the
  second line is sans. I'd bee glad to email someone viz thunderbird,
  and also send along a screenshot of how it looks while I am typing.

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/thunderbird/+bug/584632/+subscriptions