[Bug 584632]
In nsEditor::InsertTextImpl we find this code:
if (mComposition) {
...
} else {
if (node->IsNodeOfType(nsINode::eTEXT)) {
...
} else {
// we are inserting text into a non-text node. first we have to create a
// textnode (this also populates it with the text)
node->AsElement()->List(stdout,0,EmptyCString());
...
Debugging shows that when the font is lost - after clicking elsewhere and then
clicking again at the end of the line - "we are inserting text into a non-text
node". Dumping out the 'node' at this point gives:
body@1197C400 text="#00" bgcolor="#FF" _moz_dirty=""
state=[4020004] flags=[00104008] ranges:1 primaryframe=0BFDD498 refcount=62<
tt@0DAA42E0 _moz_dirty="" state=[402] flags=[0010]
primaryframe=0D3A5020 refcount=5<
Text@0C58D650 flags=[0208] primaryframe=0D3A5070 refcount=14
>
br@0DCF3D00 _moz_dirty="" state=[402] flags=[0010]
primaryframe=0BFDFA90 refcount=4<>
br@0DCF3DC0 _moz_dirty="" state=[402] flags=[0010]
primaryframe=0BFDF968 refcount=2<>
div@0DCF3E80 _moz_dirty="" class="moz-cite-prefix" state=[402]
flags=[00100400] primaryframe=0BFDFD20 refcount=4<
Text@0DCFFD80 flags=[0308] primaryframe=0BFE0088 refcount=3
br@0DCF3EE0 _moz_dirty="" state=[402] flags=[0010]
primaryframe=0BFDF8F0 refcount=2<>
>
(Note: In my test I was answering a Bugzilla e-mail and my composition style
was "tt". I had typed the word "one" before clicking elsewhere and then
clicking again after "one". On the next keystroke the above dump was produced.)
This confirms what Ehsan said in comment #22: The key to this problem is
what happens when clicking at the end of the line to continue typing. By
the looks of it, the click does not identify the correct element where
the user would like to continue typing. Instead a new node is created
which is lacking the font information.
I could use some help to locate the code that translates the click into
identifying the element. Somewhere in ns(HTML)EditorEventListener.cpp, I
suppose.
--
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
[Bug 584632]
I am having second thoughts. If I understood correctly, the idea is to continue adding to the pre-existing element at the end of the line instead of adding a new element which will lose the style or font. Is this really the correct approach? I have three more questions in this context: 1) The paragraph is created when replying to an e-mail does have the correct style/font. It only gets lost after moving the caret around in the e-mail. How does Thunderbird communicate to the editor which style to use in the first place, in the case comment #23, the ? Why can't this method be used for any subsequently created text elements? Currently further text elements are created with the "default" font, which is also configured in Thunderbird and must be communicated somehow to the editor. 2) Over in bug 1100966 (spell checker losing red underlines) another node is also created when clicking at the end of the line. Upon backspace, this node becomes empty and is merged (badly) with the preceding one, which in turn loses the underlines. Why didn't we consider to continue the existing node instead of creating a new one? In this case the merge would not happen. 3) Another problem with losing the style/font can be observed after inserting an image, see comment #14. I think the proposed approach of reusing a pre-existing text element can't be used here, since the preceding element is an image. So wouldn't it be easier to make sure the chosen style/font is observed when creating another text element after the image? -- 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
[Bug 584632]
I have to correct point 3) a little. In an e-mail with different fonts, colours, bold, italics, clicking in the editor does communicate something back to Thunderbird so it can update it's controls; or maybe the editor just sets some "global" variables, that can be queried in the UI. -- 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
[Bug 584632]
Thank you for your detailed answer which clarifies a lot of things. I will investigate the interaction between Thunderbird and the editor further. Re. your last comment: > I _think_ to fix that part you need to get Thunderbird tell Gecko about how > to format the new paragraph. I tried with a in Firefox. The editor handles insertion of images by itself. So the question is: How could Thunderbird, the invoker of the editor, be notified, so it could in turn do whatever it does normally (I need to investigate what that is exactly) to communicate that the format required after the insertion? Can an callback be installed that the editor calls when new nodes are created in the DOM tree? So far I get the following picture of the interaction between Thunderbird and the editor: 1) Thunderbird invokes the editor and communicates the initial conditions, font, size, etc. 2) The editor does all the editing. When new nodes are created in the DOM, no "special" style element is used, so to the Thunderbird user it looks like the style gets lost. 3) No callback to Thunderbird takes place while the editor is running. 4) Thunderbird may send "commands" to the editor, to change the font, bold, etc. 5) When the editing is done, Thunderbird receives a copy of the DOM (or the plain text or HTML) and stores it or sends it. -- 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
[Bug 584632]
@Ehsan from comment #30 ("I'd be curious to know, FWIW!"):
Turns out that the Thunderbird e-mail front end is one big JS/XUL application:
http://mxr.mozilla.org/comm-central/source/editor/ui/composer/content/editor.js
I haven't looked very much, but I can answer some questions. For example the
"Bold button" is defined here:
http://mxr.mozilla.org/comm-central/source/editor/ui/composer/content/editorOverlay.xul#1138
There is an observer, so when the bold state changes, it gets noticed and the
UI is updated.
I will now hunt through this code to see whether I can find the cause of
the lost font.
--
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
[Bug 584632]
Sorry to trouble you again. I have some more questions to understand how the architecture hangs together. Let me summarise the questions from the previous posts here: Where is the mouse click translated into identifying a node of the DOM tree? Your answer was nsFrame::HandlePress. I looked through there in the debugger but didn't see anything connected to the editor. nsFrame::HandlePress handles clicks anywhere on the mail composition window. I would like to find the spot where the editor looks through the DOM tree to identify the node. I looked in nsHTMLEditorEventListener::MouseDown, but in there only the very last branch controlled by "else if (!isContextClick && buttonNumber == 0 && clickCount == 1)" is executed. I would imagine to find a traversal of the DOM tree to find the correct node. How does Thunderbird communicate "composition font" or "default font" to the editor? Your answer was that you didn't know. Fair enough. You suggested the document.execCommand could be used. Assuming that this is implemented in nsHTMLDocument::ExecCommand, I set a breakpoint which wasn't reached. Equally, then the UI controls for bold, italics, font, etc. are operated, the breakpoint wasn't reached. I'd like to know how this is passed to the editor. So I will ask in the Thunderbird group. When the user writes an e-mail and clicks into a text, the UI controls are updated, that is the indicators for font, bold, italics, etc. reflect the properties of the text where the user clicked. How is this done? How does the editor notify the UI, after identifying the node clicked and the finding the properties of the node. This is also important to know, because in cases where the font gets lost, the UI is not updated correctly. And last question just repeated from comment #26. You said in comment #25: > I _think_ to fix that part you need to get Thunderbird tell Gecko about how > to format the new paragraph. I tried with a in Firefox. The editor handles insertion of images by itself. So the question is: How could Thunderbird, the invoker of the editor, be notified, so it could in turn do whatever it does normally (I need to investigate what that is exactly) to communicate that the format required after the insertion? Can an callback be installed that the editor calls when new nodes are created in the DOM tree? Note: I've just noticed that when an image, math, table, link, etc. is inserted from the "Insert" menu, the composition style is NOT lost. It is only lost when an image is *pasted* in. That's an interesting observation, leading to the question how the system manages to maintain the font in these cases, whereas on paste the font gets lost. -- 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
[Bug 584632]
Thank you for your continued patience. It is true that this bug is is about losing the font when clicking at the end of the line after clicking somewhere else. However, I'd like to consider other occasions where the font is lost, that is after inserting an image by paste. Let's deal with this "off-topic" issue first: In Firefox, using you can paste in an image and then keep typing in the font that was used before the insertion. So as you concluded, TB must be doing something strange here. As for the clicking at the end of the line: In Firefox, again with a I created two texts with different fonts, clicking in one, typing in one font, then clicking in the other one, then clicking at the end of the first one again does NOT lose the font. So maybe this is not a Core/Editor bug, maybe it's solely a Thunderbird bug. To answer your question why I was looking in the editor for the click processing: pure ignorance. Of course you can click onto a static document where no editor is involved and the click will be processed. I will follow up on the other issues with the Thunderbird group https://groups.google.com/forum/#!topic/mozilla.dev.apps.thunderbird/1xtQ_nruGcw and keep you posted. -- 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
[Bug 584632]
Without a working font indicator it is impossible to tell what's going on. So fixing bug 1139524 first. Further testing over in the other bug showed that by clicking at the end of the line sometimes the font in the next line is activated rather then the one of the line being clicked. -- 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
[Bug 584632]
Just noticed: Not only the font gets lost, also the font size can get lost. For example when replying to a message in a small font, the size gets bigger when clicking at the end after correcting something in the same line. -- 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
[Bug 584632]
Coming back to the suggestion from comment #25 and looking in nsFrame::HandlePress. I traced it down into ns[Text]Frame::GetChildFrameContainingOffset with a call stack of: nsFrame::GetChildFrameContainingOffset *or* nsTextFrame::GetChildFrameContainingOffset nsFrameSelection::GetFrameForNodeOffset nsFrameSelection::BidiLevelFromClick nsFrameSelection::HandleClick nsFrame::HandlePress It varies whether nsFrame::GetChildFrameContainingOffset or nsTextFrame::GetChildFrameContainingOffset is being called depending on whether you click on the text, but almost to the left of the text, or completely to the left of the text. When the nsTextFrame::GetChildFrameContainingOffsetAny version is called, it offset is calculated correctly and the font is right. When the nsFrame::GetChildFrameContainingOffset is called, the font is wrong. In the latter case the caret still appears behind the text. Try it with a wide letter, like "m"! So in case a "Frame" being hit instead of a "TextFrame", perhaps the program should look whether there is a text right before the caret once placed. Here some debug showing the two cases: === before BidiLevelFromClick === in nsTextFrame::GetChildFrameContainingOffset nsTextFrame::GetChildFrameContainingOffset, offset=3 === after BidiLevelFromClick === before BidiLevelFromClick === in nsFrame::GetChildFrameContainingOffset === after BidiLevelFromClick Any further hints? Five minutes of your time can possibly save me five hours or five days of "reverse engineering". -- 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
[Bug 584632]
I'm working on it, but I can mostly do the debugging. Now I need some help to actually fix the problem. If I can get that help, I can assign it to myself. Otherwise, it might wait another 10 years ;-(( Note: The predecessor bug 250539 is from 2004. -- 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
[Bug 584632]
c/left/right/g ;-) It varies whether nsFrame::GetChildFrameContainingOffset or nsTextFrame::GetChildFrameContainingOffset is being called depending on whether you click on the text, but almost to the *right* of the text, or completely to the *right* of the text. -- 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
[Bug 584632]
The problem with losing the style after inserting an image (see comment #14) has been moved to bug 1140617. -- 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
[Bug 584632]
Simple test using Midas: http://www- archive.mozilla.org/editor/midasdemo/ 1) type two lines, like shown: one two They are shown in Times. 2) select first line and make it arial, select second and make it courier 3) Click after the word "one" in the first line and type. Typing happens in Times. Wrong font. You must reload the page before trying again. -- 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
[Bug 584632]
Maybe better to look further up in call stack, for example PresShell::HandlePositionedEvent. -- 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
[Bug 584632]
Oops, after a refresh of my source, behaviour of nsFrame::HandlePress has changed, now returns early: http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#2816. Behaviour hasn't changed though. Click "far" left, font changes, click left/on, font is correct. -- 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
[Bug 584632]
Created attachment 8574843 Stripped down Midas demo, also alerts on clicks and dumps out info -- 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
[Bug 584632]
Sadly I don't understand some of what you wrote. Let me see what I understood. You're saying you want to check how other rendering engines behave. I ran the test from comment #37 on Chrome and IE. Both continue text entry with the font present on the first line, so their behaviour is what I would expect. Next you talk about "test cases" where you click and dump out the selection. In this case, we do a single click, so the selection will have one collapsed range. I don't know which property of the Selection or Range you want to inspect, maybe selRange.[start|end]Container.nodeName. I've stripped down the so-called Midas demo and added some information about the clicking when carrying out the text case from comment #37. Result: FF: BODY, continues in the wrong font. Chrome: #text, continues with the correct font. IE: #text if you used between the lines, or BODY if you used , continues with correct font in both cases. Let me know what to do next. And please, clear instructions ;-) -- 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
[Bug 584632]
Created attachment 8575104 Alternate test, much simpler Here is a much simplified test "alternate.htm". Results: FF: DIV, wrong font IE: DIV, correct font Chrome and Opera: #text, correct font. -- 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
[Bug 584632]
More results: Safari (5.1.7, had it on some old machine): Same behaviour as Chrome. Opera (27.0, fresh install): Same behaviour as Chrome. -- 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
[Bug 584632]
Please confirm that you are happy to change FF's behaviour to be like Chrome, Opera and Safari. I read the last section of your comment (quote: "... Good luck!") as a confirmation, but before you were rather careful saying (1): > If they all agree on putting the selection where I described above (...) > then we can look into changing our code and (2) > it's clear that the exiting engines don't all agree on a single behavior, > which > means that my original idea may turn out to be incompatible with the Web. :/ Regarding the first statement: They don't all agree, FF and IE differ, but if FF moved into the Chrome camp, only IE would be left. And who knows what the new "Spartan" browser will do. Regarding the second statement: I thought the original idea from comment #22 was to move the selection into the text: > My suspicion is that place is outside of the element that has the respective > style > for the font set. We should probably look into normalizing the selection in > those cases to be inside the said element Also in comment #50 you said: > As I said in comment 22, we should probably look into normalizing the > selection, > so that if the line ends in an inline frame containing a text frame, we should > put the selection at the end of the text frame as opposed to at the end of > the inline > frame terminating the line. I'm not sure how that would be (quote) "incompatible with the Web". Once I have your confirmation I will go ahead. For me, this is the single most annoying bug in Thunderbird which after 10 years should finally be resolved. -- 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
[Bug 584632]
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() Line 2776C++
nsFrame::HandleEvent() Line 2562C++
nsPresShellEventCB::HandleEvent() Line 507C++
mozilla::EventTargetChainItem::HandleEventTargetChain() Line 346C++
mozilla::EventDispatcher::Dispatch() Line 634C++
PresShell::DispatchEventToDOM() Line 8168C++
PresShell::HandleEventInternal() Line 8064C++
PresShell::HandlePositionedEvent() Line 7896C++
PresShell::HandleEvent() Line 7689C++
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
[Bug 584632]
Created attachment 8576184 Alternate test, take 2, dumping out more info Results: FF: start=DIV(2) - end=DIV(2) IE 10 and 11 (current): start=DIV(2) - end=DIV(2) Chrome 41 (current): start=#text(10) - end=#text(10) Opera 28 (current): start=#text(10) - end=#text(10) Safari 5.1.7 (old): start=#text(10) - end=#text(10) -- 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
[Bug 584632]
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 These functions fire when you hover over or click into the URL field (or the search box), but NOT the rendered HTML. 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". -- 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
[Bug 584632]
Created attachment 8576320 A more comprehensive text 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? 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 follows, then you can click far to the right and the text is still selected. Also for text in 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. 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. -- 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
[Bug 584632]
Any idea why TypeInState::NotifySelectionChanged is never called when clicking around in a ? http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/TypeInState.cpp#75 Is that not a listener to listen to the selection changing? Maybe that has something to do with our problem(s) (thinking also of bug 1140617). -- 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
[Bug 584632]
You are correct, I was in "e10s" mode and there was another process "plugin-container". Now I switched that off. I had noticed that my debugging had become strange, but couldn't figure out why. So thank you! Before considering changing the selection behaviour, I'd like to repeat my question, but I don't want to infuriate you ;-) The problem in this bug and in the other bug 1140617 is, that a line is continued with a new element. In this bug, someone clicks on a "DIV", since they click to the right of the text. The new text is inserted into a new element and loses the font. In the other bug, an image is inserted. After that the new text is inserted into a new element and loses the font. In both cases we could look in the inline frame and see whether there is a text element immediately before, whose attributes should be used. Is this an option? If we did that, we would *not* have to change the selection behaviour and wear all the possible consequences. Changing the selection will fix this bug but not the other bug 1140617. If this is not a viable solution, I can look further into changing the selection behaviour. My debugging works now: Debug when clicking on the text: >>> Entering nsFrame::HandlePress === in nsIFrame::GetContentOffsetsFromPoint === in GetSelectionClosestFrame === in nsFrame::GetSelectionClosestFrameForBlock >>> Entering nsFrameSelection::HandleClick === before BidiLevelFromClick >>> Endering nsTextFrame::GetChildFrameContainingOffset === nsTextFrame::GetChildFrameContainingOffset, offset=10 <<< Leaving nsTextFrame::GetChildFrameContainingOffset === after BidiLevelFromClick *** TypeInState::NotifySelectionChanged, container=05EF8900, offset=10 <-- the text of length 10 <<< Leaving nsFrameSelection::HandleClick after TakeFocus <<< Leaving nsFrame::HandlePress When clicking to the right of the text: >>> Entering nsFrame::HandlePress === in nsIFrame::GetContentOffsetsFromPoint === in GetSelectionClosestFrame === in nsFrame::GetSelectionClosestFrameForBlock === in nsFrame::GetSelectionClosestFrameForLine === in GetSelectionClosestFrame === in nsFrame::GetSelectionClosestFrameForBlock >>> Entering nsFrameSelection::HandleClick === before BidiLevelFromClick === after BidiLevelFromClick *** TypeInState::NotifySelectionChanged, container=066CF4C8, offset=2 <-- the DIV <<< Leaving nsFrameSelection::HandleClick after TakeFocus <<< Leaving nsFrame::HandlePress -- 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
[Bug 584632]
Created attachment 8576888 three line change to fix a 10 y/o problem ;-) Skipping brFrames when determining the closest frame in a line. Can only skip if the brFrame isn't the only selectable non-empty frame in the line. Otherwise one couldn't click in that line at all. Need to be careful since ranges can become empty during editing. -- 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
[Bug 584632]
Sorry, you need to help me out here. Never done it before. I will get the access rights as discussed on IRC. -- 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
[Bug 584632]
When you have a minute, could you please look at the results or instruct me, how to interpret them. -- 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
[Bug 584632]
@Aryeh: Yor comment really surprises me given the following: In comment #68 Ehsan said: > Good start, but this is still *far* from being ready for review. In comment #60 Ehsan said: > This affects more than just Thunderbird, and concerns behavior that is > visible to Web pages. > Web content can rely on the behavior of the engine in a lot of ways, for > example by expecting > that Firefox puts the selection somewhere specific when you go to the end of > line. > This is one of the reasons why fixing this bug is *very difficult*. Also, we need to keep the sister bug 1140617 in mind. In bug 1140617 comment #8 Ehsan said: > We still don't have a complete fix for bug 756984. The stuff that you're > working on is > just the tip of the *iceberg*. Can you please just *trust me* on this and > wait for bug > 756984 to be finished before worrying about this? Thanks! To me, it's just a three line change, and if you want, with a test case. Obviously none of the other tests checks the selection after the click, so I can certainly add such a test following your suggestions. However, before I start, I want to make 100% sure that we're all on the same page. I have the impression that Ehsan has something grander in mind. -- 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
[Bug 584632]
Thanks for the suggestions made in comment #78. I'm testing with foo bar on the same line foo bar on the same line foo bar on the same line This is strikethrough 25 m2 H2SO4 and some underline foobar Moving around with the cursor already works with the current version of FF, including moving from a long line to a short one and getting to the end this way. Pressing the "End" button is sadly NOT fixed by the patch. Clicking at the start of a line and then pressing "left arrow" to get to the end of the previous line is also NOT fixed by the patch. So the next step is to fix the two mentioned cases: End button and "left arrow" at the start of the line. BTW, these two cases do work in Chrome and IE already. I'd like to make sure that all positioning actions end up with the same correct result, clicking is only one of them. -- 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
[Bug 584632]
Created attachment 8582360 Patch to fix all three problems: Click, "end" key, left arrow from start of previous line Can you please push this to the try server for me and tell me the exact steps to do it. I was reading https://wiki.mozilla.org/ReleaseEngineering/TryServer#How_to_push_to_try and http://trychooser.pub.build.mozilla.org/ I don't know which tests we need to run here and on which platforms. I'm also struggling with Mercurial. This https://developer.mozilla.org/en/docs/Mercurial_FAQ apparently is out of date. I got to the "hg qnew", the patch is enclosed. I tried "hg commit" but got "abort: cannot commit over an applied mq patch". Hmm. -- 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
[Bug 584632]
Created attachment 8582014 four line change to fix a 10 y/o problem ;-) Here's a new patch. This fixes click beyond end of line *and* "end" key. Still open: Left arrow at the start of the subsequent line. -- 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
[Bug 584632]
Created attachment 8582931 Unified patch (code + test changes) ready for next push to try. Pushed to try server (thanks guys for the support!): https://treeherder.mozilla.org/#/jobs?repo=try&revision=9782fa678cd1 Aryeh: Please help me review the results. Actually, I followed what was suggested for the try: try: -b do -p all -u all[x64] -t none Just out of interest: Why build on all platforms and then just execute on Linux? I mean, why build it in the first place? Just to see that it compiles? If it already compiled once, and I only rerun tests, that doesn't make too much sense. Further steps: If this try run goes well, the only thing missing is a test for the changes I made. Two scenarios are already covered by the existing tests which I had to change: the "moving around with the left arrow" and the "jumping to the end of the line with a key stroke". What's missing is the "clicking beyond the end of the line". The first try run in comment #71 was done with only the code to fix the clicking. No tests failed, so there wasn't a test for this, so it needs to be added now. -- 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
[Bug 584632]
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #87) > I realized that I forgot about another case that we need to test. br frames > are not the only reason for a line ending, we can also get line breaks at > block boundaries, for example: block 1new line > hereblock2 This works already. My patch only tries to skip brFrames. In this example there is no brFrame at the end of "new line here". -- 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
[Bug 584632]
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #88) > Nit: you don't need to mention bug numbers in comments. This information is > available through hg/git blame. There are many bug numbers in the code (including some that you entered for bug 596506), so this policy must have changed recently. > Also, please wrap if bodies in braces. Again, the policy seems to have changed here since there are many conditions of this style: if (!range.content) return NS_ERROR_FAILURE; > There is already code which gets the line frame count earlier in this > function. Please refactor it out of the else block it currently lives in > and just use lineFrameCount from that code here. That already takes care of > checking the return value of GetLine for errors too. Also, I think you want > to check atLineEdge instead of aJumpLines here. I disagree. I did what you suggest, but it didn't work. The it->GetLine(thisLine, &firstFrame, &lineFrameCount, nonUsedRect); ealier on gets the details for the previous line where the left arrow was pressed. We then move on to the line before. The next it->GetLine(currentLine, ¤tFirstFrame, &lineFrameCount, usedRect); is operating on the line we've just moved to, the one where we want to skip the brFrame. The only thing which would be a bit cleaner is not to re-use the "it" variable but to declare another one. I agree, I do need "atLineEdge". -- 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
[Bug 584632]
Thanks, the "mach mochitest-chrome" worked, I will supply a fixed test tomorrow (now after 12 AM here). I assume I can just push a "unified" patch with the code and the updated tests to the try server. -- 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
[Bug 584632]
Created attachment 8582923 Easy fix for test due to new selection behaviour (move commands) This is the last of the updated tests. -- 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
[Bug 584632]
Created attachment 8582686 Easy fix for test due to new selection behaviour (layout/generic) -- 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
[Bug 584632]
These tests are a little mysterious. I wanted to look at editor/libeditor/tests/test_selection_move_commands.xul first. Sadly mach mochitest-plain editor/libeditor/tests/test_selection_move_commands.xul doesn't work? I've run single tests before, but they weren't XUL files. So I ran mach mochitest-plain editor/libeditor/tests/ and got: 7043 INFO TEST-UNEXPECTED-PASS | editor/libeditor/tests/browserscope/test_richte xt2.html | Browserscope richtext2 selection: S-Proposed-SM:e.f.lb_BR.BR-1_SC-1-d M - 1 should equal 1 TEST-INFO | expected FAIL 7044 INFO TEST-UNEXPECTED-PASS | editor/libeditor/tests/browserscope/test_richte xt2.html | Browserscope richtext2 selection: S-Proposed-SM:e.f.lb_BR.BR-1_SC-1-b ody - 1 should equal 1 TEST-INFO | expected FAIL 7045 INFO TEST-UNEXPECTED-PASS | editor/libeditor/tests/browserscope/test_richte xt2.html | Browserscope richtext2 selection: S-Proposed-SM:e.f.lb_BR.BR-1_SC-1-d iv - 1 should equal 1 TEST-INFO | expected FAIL 7046 INFO TEST-UNEXPECTED-PASS | editor/libeditor/tests/browserscope/test_richte xt2.html | Browserscope richtext2 selection: S-Proposed-SM:e.f.lb_BR.BR-1_SM-1-d M - 1 should equal 1 TEST-INFO | expected FAIL 7047 INFO TEST-UNEXPECTED-PASS | editor/libeditor/tests/browserscope/test_richte xt2.html | Browserscope richtext2 selection: S-Proposed-SM:e.f.lb_BR.BR-1_SM-1-b ody - 1 should equal 1 TEST-INFO | expected FAIL 7048 INFO TEST-UNEXPECTED-PASS | editor/libeditor/tests/browserscope/test_richte xt2.html | Browserscope richtext2 selection: S-Proposed-SM:e.f.lb_BR.BR-1_SM-1-d iv - 1 should equal 1 TEST-INFO | expected FAIL 7049 INFO TEST-UNEXPECTED-FAIL | editor/libeditor/tests/test_bug1068979.html | S hould have four SMP characters - got 𝐀𝐀, expected 𝐀𝐀𝐀𝐀 7050 INFO TEST-UNEXPECTED-FAIL | editor/libeditor/tests/test_bug1068979.html | T hree complete characters should remain - got 𝐀, expected 𝐀𝐀𝐀 7051 INFO TEST-UNEXPECTED-FAIL | editor/libeditor/tests/test_bug1068979.html | T wo complete characters should remain - got , expected 𝐀𝐀 7052 INFO TEST-UNEXPECTED-FAIL | editor/libeditor/tests/test_bug1068979.html | O nly one complete SMP character should remain - got , expected 𝐀 7053 INFO TEST-UNEXPECTED-FAIL | editor/libeditor/tests/test_bug410986.html | Co ntent should be pasted in plaintext format - got , expected green text 7054 INFO TEST-UNEXPECTED-FAIL | editor/libeditor/tests/test_bug410986.html | Ti med out while polling clipboard for pasted data. - expected PASS 7055 INFO TEST-UNEXPECTED-FAIL | editor/libeditor/tests/test_bug410986.html | Fa iled to copy the second item to the clipboard - expected PASS 7056 INFO TEST-UNEXPECTED-FAIL | editor/libeditor/tests/test_bug551704.html | Ti med out while polling clipboard for pasted data. - expected PASS SUITE-END | took 376s So we got a few TEST-UNEXPECTED-PASS, we already new that. No sight of test_selection_move_commands.xul, but there are other failures that don't appear in https://treeherder.mozilla.org/#/jobs?repo=try&revision=fd11f71e3daa Yes, I'm running the text on Windows 7, not on Linux, but still. -- 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
[Bug 584632]
Comment on attachment 8582686 Easy fix for test due to new selection behaviour (layout/generic) This fixes the failed test in layout/generic. More to come. -- 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
[Bug 584632]
(In reply to :Aryeh Gregor from comment #84) > A good try line to use by default for editor changes is: > try: -b do -p all -u all[x64] -t none OK, but how do I send the patch to the try server? I have my "level 1" access rights and I believe SSH is set up correctly. I tried hg push -f ssh://mozi...@jorgk.com@hg.mozilla.org/try/ *before* coming across the "hg qnew" command. It returned: "No changes found" or words to that extent. I haven't tried after the "hg qnew". So what is the exact sequence of commands? BTW, I'm on Windows 7. 30 seconds of your time save me three hours of (very frustrating) research (since I want to focus on the problem and not the infrastructure). As for the test results: Mochitests 4, 5 and oth failed. I just had a very brief look: oth says: editor/libeditor/tests/test_selection_move_commands.xul | node after cmd_selectEndLine - got [object Text], expected [object HTMLBodyElement] YES! Indeed, we want the text. I will need to change the test. 5 says: layout/generic/test/test_movement_by_characters.html | Left movement broken in H K - got [object Text], expected [object HTMLDivElement] Same thing, we want the text. 4 says: TEST-UNEXPECTED-PASS a few times, so let's how that's a change for the better. However, this stuff worries me (3x crashed, 1x time out) 965721 Intermittent test_bug409604.html, test_bug719533.html, test_richtext2.html, test_bug412567.html | application crashed [@ imgStatusTracker::RecordCancel()] 969526 Intermittent test_richtext.html,test_richtext2.html,test_bug436801.html | application crashed [@ KERNELBASE.dll + 0x89ae4] (ABORT: Should have mProgressTracker until we create mImage: 'mProgressTracker') 1129538 Intermittent test_draggableprop.html,test_richtext2.html | application crashed [@ mozalloc_abort(char const*)] after "ABORT: Should have given mProgressTracker to mImage: '!mProgressTracker', file /image/src/imgRequest.cpp, line 149" 1142900 Intermittent test_richtext2.html | application timed out after 330 seconds with no output Any comments on these crashes and time-outs? P.S.: Would you be able to let me know your time-zone so I know when not to expect feedback ;-) -- 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
[Bug 584632]
Created attachment 8582633 Patch to fix all three problems: Click, "end" key, left arrow from start of previous line (updated coding style) Here's the updated code according to the review. I will review the test failures next. -- 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
[Bug 584632]
Is it worth running it on other systems as well since I found some - most likely unrelated - problems (see comment #97) when running it locally on Windows 7? Or are these known problems that always fail? -- 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
[Bug 584632]
Created attachment 8582701 Easy fix for test due to new selection behaviour (richtext2) Removed tests which now no longer fail due to changed selection behaviour. I'd appreciate some help with the stuff from comment #97: How do I run test_selection_move_commands.xul separately and what do I make of the additional unexpected failures? -- 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
[Bug 584632]
Created attachment 8583259 Test case Here is the test case. Forgive me if the JS is bad, I've never written any, just copied bits and pieces around. Two questions: Where in the mochitest.ini do I put my new test? I put it right at the front since I don't understand the syntax of "skip-if". Does that skip the next line? Perhaps you can suggest a line where it should go. Or say: After such and such. In the test I use a 123 to get offset 3 when clicking behind it. Without the span, I get offset 4, which I find surprising, or clicking at the front gives offset 1 instead of 0. FF 36 does the same, so I guess it's right, but I'd like to understand why 4 and not 3, or 1 and not 0. Why does the span make a difference? Anyway, the tests are passed. Without my changes, the first test fails as expected. As I said in comment #106: There are already tests for hitting the "end" key and navigating with the arrow keys, so this test should be the only one we need additionally. -- 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
[Bug 584632]
I'll revise the test and post a new one in a second. -- 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
[Bug 584632]
Created attachment 8583354 Test case (revised) If this is good to go, I'll submit another "unified" patch (code + all tests), if necessary. -- 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
[Bug 584632]
Created attachment 8584346 Unified patch (code + test changes + twice revised new test) Thank you very much for the review and all the additional explanation. I hope I could address your questions in additional comments in the test. Sadly switching from "mousedown/up" to "click" as you had suggested makes the test fail with: failed | uncaught exception - NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.sendMouseEvent] at chrome://specialpowers/content/specialpowersAPI.js:161 This is actually the only test I intended to submit ;-) This is for the case where the user clicks beyond the end of the line. There are two tests already which I had to adapt to the new selection behaviour which test the moving to the end (editor/libeditor/tests/test_selection_move_commands.xul) and moving from the subsequent line using left arrow (layout/generic/test/test_movement_by_characters.html). If you wanted to be really purist a test with a "div contenteditable" could be added where an empty line is first filled with some text, which is then removed so the range becomes empty. The code caters for this case. -- 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
[Bug 584632]
Created attachment 8584639 Unified patch (code + test changes + four times revised new test) This should be good to go then ;-) -- 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
[Bug 584632]
Created attachment 8584608 Unified patch (code + test changes + three times revised new test) Here comes the updated test. This time with some additional inline elements. I'm not sure why the second test should be wrong, I'll add another attachment in a second to convince you ;-) -- 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
[Bug 584632]
(In reply to Charles from comment #124) IMHO the problem is in the coupling between TB and FF. I think it's quite reasonable that the FF people are more conservative. Who would want to break a browser with a big market share. TB on the other hand is client software. An nothing should stop client software to pick its foundation and additional patches. I've seen client software (KompoZer, or for example KDE with its so-called "build dependencies") where I couldn't believe my eyes how much they patch the underlying components. This discussion, however, should be continued elsewhere. -- 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
[Bug 584632]
(In reply to Charles from comment #121) > Are you seriously saying that this bugfix will NOT land in time for TB 38? > Meaning, we will have to another full YEAR to see it fixed? Given that the version spacing is six weeks we get 6 * (45-38) = 42 weeks, that's 10 months ;-) However, everyone is free to compile their own version, which is what I'll do. -- 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
[Bug 584632]
Created attachment 8584620 Here comes another manual test. Here some HTML to run a test by hand. If clicking behind any of the eight lines in this test, "DIV" will be returned in the current version of FF. With the new behaviour clicking behind lines 1-6 and 8, "#text" will be returned, but for the empty line 7, DIV is still returned. If the code were wrong, this line couldn't be clicked at all and the caret would move to the previous or subsequent line. I know, because at first my code didn't cater for this case. IMHO my test is correct, if you don't think so, please be more specific. Changing the subject: I'd like to see this landed one day very soon. I'd also request to land it on mozilla38, so TB 38 can pick it up. I don't want to mention again that this is fixing a long-standing TB bug that people have been pulling their hair out for over 10 years now. If you really want more tests to be written, I can do that, but *afterwards* ;-) -- 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
[Bug 584632]
(In reply to maybe-the-one from comment #135) > Personally, I never understood why this problem involved browsers at all. That you don't understand the facts doesn't change them ;-) Let me explain: Thunderbird is client software that sits on top of Mozilla core software. The so-called "editor" that is used in Thunderbird when writing an e-mail messase is Mozilla core software. It is also used in Firefox: Please go to http://www- archive.mozilla.org/editor/midasdemo/ to check that even in Firefox you can "write". The problem happens when losing the font goes unnoticed while writing. You will notice it when reading a reply that contains your original ill- formatted message. The (In reply to Charles from comment #134) > Ummm... ok, but... who are these 'Thunderbird people', and how do we contact > them? They are aware of the problem via this meta bug 1142879. -- 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
[Bug 584632]
Created attachment 8515218 composition font also lost after insertion of image. Composition font is also lost after inserting an image in a new message. Watch the enclosed video. I am using these settings: Options: Display, Formatting, Default Font: Arial. Options: Composition, HTML, Font: Fixed width. -- 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
[Bug 584632]
Created attachment 8515199 Two videos showing the problem. Here are two cases to reproduce the problem. CASE 1: === Step 1: Set the following options: Options: Display, Formatting, Default Font: Script Options: Composition, HTMl, Font: Batang Step 2: Reply to an e-mail written in Arial. Start typing in Batang. Click into the quoted text. Font changes to Arial. Step 3: Click after the text written in Batang. Font says Arial but we write in Script (default font). Result: After returning to the end of the line, the font is lost, the composition continues in the default font and the in the HTML the text is outside the tags. The UI shows incorrect information. Message saved/sent has this HTML: We have done little to address this trend. This is batang. This is script See video 1 enclosed. CASE 2: === Step 1: Set the following options: Options: Display, Formatting, Default Font: Batang Options: Composition, HTMl, Font: Batang Step 2: Reply to an e-mail written in Arial. Start typing in Batang. Click into the quoted text. Font changes to Arial. Step 3: Click after the text written in Batang. Font says Arial but we write in Batang (default font). Result: After returning to the end of the line, the font is lost, the composition continues in the default font and the in the HTML the text is outside the tags. The UI shows incorrect information. Message saved/sent has this HTML: We have done little to address this trend. This is batang. We continue to write in batang, or so it seems. See video 2 enclosed. -- 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
[Bug 584632]
(In reply to :Aryeh Gregor from comment #16) > Unfortunately, we have no one actively working on the editor component, so > basically all editor bugs on indefinitely on hold. Occasionally one or two > gets fixed here or there, but as things stand, I wouldn't count on it. OK, when you say "editor" you mean "composer". The component that allows the user to more or less WYSIWYG enter text (with fonts, colour, etc.) and pictures and creates HTML which is sent out. Charles beat me to it, but I thought this is being worked on, quoting: https://mail.mozilla.org/pipermail/tb-planning/2014-October/003499.html === The Addressing bugs are due to some significant movement on getting the Composer rewrite going. This is a very *good* thing. It is painful when bugs like this show up, yes, but the composer has been needing the rewrite for 10+ years, so I for one am glad it is happening. === I've certainly experienced a few of the regressions (bug 1042561 and bug 1043310). -- 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
[Bug 584632]
>From Bug 250539 (In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!, PTO 11/3-11/21) from comment #196) 2010-08-25 07:18:58 PDT > It appears to me that this is an editor bug. If someone can create a test > case as an HTML file and file a bug in Core::Editor, I may try to sneak a > fix in for Gecko 2.0. (In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!, PTO 11/3-11/21) from comment #232) 2011-09-22 19:46:20 PDT > Everyone, please relax. I'm working hard to work out a solution to this > bug. What happened to that? The test case is here. Is this a super-hard problem? To me at seems that it's just a simple special case: If cursor is moved to the very end of the text, pick up the font that was previously used. -- 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
[Bug 1360086]
Please land for ESR31. One question: Landing this on 35 (comment #43 and comment #44) means that we will see it in beta 36 one day soon now? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1360086 Title: Thunderbird 31 regression: changing focus with in compose window during address autocompletion To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1360086/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1360086]
Since the fix to bug 1043310 (and therefore bug 1107844) has landed for ESR31, this fix should probably be put back in for ESR31, right, Magnus? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1360086 Title: Thunderbird 31 regression: changing focus with in compose window during address autocompletion To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1360086/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1229172]
Can this bug be resolved? I was fixed in Oct. 2013. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1229172 Title: Thunderbird "Spell check as you type" stopped working after update to 1:24.0+build1-0ubuntu0.12.04.1 (precise-updates) To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1229172/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1229172]
This bug is about a fault in TB v 24 which was fixed in 24.0.1. The error was that inline spell-checking didn't not work at all. The effect that you're observing is a different bug that I have reported in bug 1100966. Once again: Please close this bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1229172 Title: Thunderbird "Spell check as you type" stopped working after update to 1:24.0+build1-0ubuntu0.12.04.1 (precise-updates) To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1229172/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1229172]
@al...@yahoo.com: Please resolve the bug. There are too many inactive bugs in the system with unknown state dangling around for years. This bug is resolved, it should be marked resolved. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1229172 Title: Thunderbird "Spell check as you type" stopped working after update to 1:24.0+build1-0ubuntu0.12.04.1 (precise-updates) To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1229172/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1229172]
@al...@yahoo.com: Please resolve the bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1229172 Title: Thunderbird "Spell check as you type" stopped working after update to 1:24.0+build1-0ubuntu0.12.04.1 (precise-updates) To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1229172/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
