(In reply to Jorg K from comment #51) > 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.
That's not what I asked. I want to know where they put the selection. Attachment 8575104 kind of does that but I was hoping to get the offsets as well, but with the results in comment 54, 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. :/ What versions of these browsers did you test? What about Safari? Note that whether or not other engines have this bug is not relevant. > 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. Yeah, startContainer and endContainer, plus startOffset and endOffset. > 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 <enter> between the lines, or BODY if you used > <shift><enter>, continues with correct font in both cases. > > Let me know what to do next. And please, clear instructions ;-) The first step is to read and understand how GetContentOffsetsFromPoint() works, specifically the call to GetSelectionClosestFrame(), which is the function that decides what frame is marked as selected ultimately when a given frame receives a click event. For example in attachment 8575104 if you click to the right of the first line, we get to GetSelectionClosestFrameForLine() selecting the BRFrame at the end of the first line. Now, if we want to collapse the selection to the text frame, it means that we need to skip the BRFrame. So you should modify that logic to ignore BRFrame's if there is anything else on the same line before them (i.e., if there is something that we haven't yet looked at through the line iterator.) Then you should verify that the change actually makes us collapse the selection at the end of the text frame (so for example startContainer and endContainer should both be the text node and startOffset/endOffset should both be 10 depending on the length of the text frame). Then you should post the change to the try server and see what existing tests fail, and debug them to figure out why. There will be two classes of test failures, one for tests that are relying on the specific behavior we're changing here, so you should adjust those tests accordingly. Another set of test failures will hopefully catch the edge cases that we have not thought very carefully about yet. We should probably discuss the test failures once you get to that stage. Beware that this will probably be a lengthy process and it requires a lot of debugging skills and also being comfortable finding your way across a large C++ code base. Good luck! -- 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
