4ad88cfd05b50399ab02a3814361c9cebacffefd: Bug 1293250 - Make reftest log generation less magical, r=ahal
James Graham <james@hoppipolla.co.uk> - Mon, 08 Aug 2016 17:48:39 +0100 - rev 400399
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1293250 - Make reftest log generation less magical, r=ahal Ensure that the first line of the log for failing tests is identical to one that would be produced by the tbplformatter from mozlog. This means that treeherder will be able to sucessfully cross-match error lines. Also make the data structures used for storing screenshots identical between reftests and web-platform-tests so that we can start to move toward removing the reftest-specific codepath here. MozReview-Commit-ID: FZQXLjj9Ejv
782f590541b8173cd1b073a88732afa601f05715: Bug 1287910 - move devtools stack-related APIs to per-platform require; r=jryans
Tom Tromey <tom@tromey.com> - Fri, 05 Aug 2016 13:17:17 -0600 - rev 400398
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1287910 - move devtools stack-related APIs to per-platform require; r=jryans MozReview-Commit-ID: CgT1VGJnJqB
a31f07fbdc2e249f76469bc897bcad548a892417: Bug 1292321 - Pressing tab key in address bar selects one-off search buttons instead of the entries in the history dropdown list. r=florian
Drew Willcoxon <adw@mozilla.com> - Thu, 11 Aug 2016 14:46:02 -0700 - rev 400397
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1292321 - Pressing tab key in address bar selects one-off search buttons instead of the entries in the history dropdown list. r=florian MozReview-Commit-ID: 6hbW7n5jiLS
89ba380478e36de087ba1c046b60363b956d4abc: Bug 1293300 - Accidental one-off search if mouse pointer hovers over a search engine when typing in location bar and pressing enter. r=florian
Drew Willcoxon <adw@mozilla.com> - Thu, 11 Aug 2016 13:56:25 -0700 - rev 400396
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1293300 - Accidental one-off search if mouse pointer hovers over a search engine when typing in location bar and pressing enter. r=florian MozReview-Commit-ID: 53MGnGs6CxF
d99ed7fbe3118be0204980a4119044ec30628382: Bug 623917 - Add basic client authentication tests. r=keeler
Cykesiopka <cykesiopka.bmo@gmail.com> - Fri, 12 Aug 2016 16:36:43 +0800 - rev 400395
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 623917 - Add basic client authentication tests. r=keeler This patch adds tests for the core aspects of the client authentication code, mainly to ensure the client auth process even works. MozReview-Commit-ID: DzV4BuwlrDE
58f7284ec7fe447807ee7a0d34b21dd154a9321c: Backed out changeset 824dd062b8e3 (bug 1288817) for startup precompilation bustage. r=backout on a CLOSED TREE
Sebastian Hengst <archaeopteryx@coole-files.de> - Fri, 12 Aug 2016 20:18:10 +0200 - rev 400394
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Backed out changeset 824dd062b8e3 (bug 1288817) for startup precompilation bustage. r=backout on a CLOSED TREE
f710f7b260052f0dfc570b1f42f89cf17d891142: Backed out changeset 79df306f1d11 (bug 1288817)
Sebastian Hengst <archaeopteryx@coole-files.de> - Fri, 12 Aug 2016 20:16:58 +0200 - rev 400393
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Backed out changeset 79df306f1d11 (bug 1288817)
48873ebb15604bc0f5051d5d1938b7a27d6e8caf: Backed out changeset 1bc60cfdc088 (bug 1288817)
Sebastian Hengst <archaeopteryx@coole-files.de> - Fri, 12 Aug 2016 20:16:54 +0200 - rev 400392
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Backed out changeset 1bc60cfdc088 (bug 1288817)
0cd9b31c572921a35364f952353e5ec596e22faa: Bug 1292715 - Added installer source code for MSYS2 and ConEmu. r=gps
Nathan Hakkakzadeh <nhakkakzadeh@mozilla.com> - Wed, 10 Aug 2016 15:30:07 -0700 - rev 400391
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1292715 - Added installer source code for MSYS2 and ConEmu. r=gps Also, is a ConEmu preferences file which automatically points a newly installed ConEmu to the newly installed MSYS2. MozReview-Commit-ID: FBeMat4SYjK
2d44cda68a5331a2130c80a05b7a58d7d3524356: Bug 1286464 part.19 ContentEventHandler::OnQueryTextRect() should handle the case when queried range starts from the end of mRootContent r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 12 Aug 2016 14:57:33 +0900 - rev 400390
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1286464 part.19 ContentEventHandler::OnQueryTextRect() should handle the case when queried range starts from the end of mRootContent r=smaug First, when the first node causing text is invisible, OnQueryTextRect() still fails even with this patch. We shouldn't fix it in this bug because it's unusual case but this bug is very important especially for some web service using HTML editor like Gmail. This patch fixes all cases when the start offset of queried range reaches the end of mRootContent. 1. When the last node causing text is a <br> element (either content <br> element or moz-<br> element), its frame is a placeholder for empty line. Therefore, this patch sets the rect to the frame rect. 2. When the last node causing text is a text node, the last frame generated for it represents its line (including empty line). Therefore, this patch sets the rect to the result of GetLineBreakerRectAfter(). 3. When the last node causes a line breaker before it, the frame may be a placeholder for it (this is not usual case, when user types Enter key at the end of <p> element, <p><br></p> is generated by Gecko). In this case, this patch sets a possible caret rect which is guessed from the content box of the frame and its font height. 4. When there are no nodes causing text in mRootContent, this patch sets a possible caret rect like case #3. MozReview-Commit-ID: FS9cWJQ39DK
7f2ba877b1026164953e7d4657c4cfd03d4b2678: Bug 1286464 part.18 ContentEventHandler::OnQueryTextRectArray() should compute line breaker's rect with the last character's node when the start of queried range is a line breaker and it's caused by a block frame r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 08 Aug 2016 19:05:35 +0900 - rev 400389
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1286464 part.18 ContentEventHandler::OnQueryTextRectArray() should compute line breaker's rect with the last character's node when the start of queried range is a line breaker and it's caused by a block frame r=smaug Similar to OnQueryTextRect(), OnQueryTextRectArray() should compute a line breaker's rect with the last character when it's the first character in queried range and not caused by <br> frame. MozReview-Commit-ID: CGDHbcrc6zB
666e845c97f4095b4d6fc68ae9cd079eff56eb39: Bug 1286464 part.17 ContentEventHandler::OnQueryTextRect() should compute a line breaker's rect from the last text frame if the queried range starts with a block frame r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 08 Aug 2016 18:11:11 +0900 - rev 400388
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1286464 part.17 ContentEventHandler::OnQueryTextRect() should compute a line breaker's rect from the last text frame if the queried range starts with a block frame r=smaug When queried range starts with a block frame, we cannot compute proper line breaker's rect at its open tag only with the frame's rect because the proper rect should be at the end of previous text frame. Therefore, this patch makes SetRangeFromFlatTextOffset() return the last text node found at scanning the range. Then, OnQueryTextRect() can compute the first line breaker's rect with it (if there is at least one text node). However, if the last text node is hidden by CSS or something, this patch won't work. We need to do something in another bug for hidden frame's issue, though. But note that IME typically doesn't request hidden text's rect because neither selection nor composition string is in such range. MozReview-Commit-ID: 2FFzNoubJ1y
edbd15e9aa9f325edfa01dedcd3c2ad04f127f76: Bug 1286464 part.16 Rename ContentEventHandler::Get*FrameHavingFlatTextInRange() to ContentEventHandler::Get*FrameInRangeForTextRect() and make them treat a moz-<br> element as a normal <br> element because it doesn't cause text but needs to compute text rect in the last empty line r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 02 Aug 2016 14:00:32 +0900 - rev 400387
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1286464 part.16 Rename ContentEventHandler::Get*FrameHavingFlatTextInRange() to ContentEventHandler::Get*FrameInRangeForTextRect() and make them treat a moz-<br> element as a normal <br> element because it doesn't cause text but needs to compute text rect in the last empty line r=smaug In plain text editor, moz-<br> element is appended for a placeholder of empty line when the text ends with a line breaker. Therefore, when we compute text rects, we need to handle it same as a normal <br> element even though it doesn't cause any text. MozReview-Commit-ID: 4IXLafU6o0W
cbcfb7b9a51354fc6bbf51d0ff8274197071c49f: Bug 1286464 part.15 Rewrite ContentEventHandler::OnQueryTextRect() with new utilities like ContentEventHandler::OnQueryTextRectArray() r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 12 Aug 2016 14:11:33 +0900 - rev 400386
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1286464 part.15 Rewrite ContentEventHandler::OnQueryTextRect() with new utilities like ContentEventHandler::OnQueryTextRectArray() r=smaug Although, this patch is pretty big and complicated, but I have no idea to separate this since this rewrites all over the OnQueryTextRect() with new utility methods which are implemented for OnQueryTextRectArray(). Currently, OnQueryTextRect() doesn't support line breaks before block level elements. Therefore, in HTML editors, eQueryTextRect may not work fine if the range includes open tags of block level elements. This causes odd positioning of IME's candidate window in non-e10s mode. This implements ContentEventHandler::GetLastFrameHavingFlatTextInRange() which scans the given range from last to first. However, this hits wrong NS_ASSERTION() in nsContentIterator::Last(). mLast can be nullptr if there is no content but Init() returns NS_OK even in such case. I think that returning NS_OK is fine because it's not illegal case. Therefore this patch fixes the wrong assertion. MozReview-Commit-ID: E6OnIA1eMou
29f03b7552fc69493af9aee3cf2e8c5026093927: Bug 1286464 part.14 When ContentEventHandler::OnQueryTextRectArray() reaches the end of query range, it should append caret rect at the end of the content r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 05 Aug 2016 16:51:49 +0900 - rev 400385
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1286464 part.14 When ContentEventHandler::OnQueryTextRectArray() reaches the end of query range, it should append caret rect at the end of the content r=smaug When the loop in ContentEventHandler::OnQueryTextRectArray() reaches at the end of contents, it should append a caret rect at the end of the contents. That helps deciding popup position of IME when caret is at the end of the contents. This patch guesses the caret rect with eQueryTextRect event (for avoiding the dependency of native caret position of eQueryCaretRect event handler). MozReview-Commit-ID: 8cGeHpkzX9g
dfd910cbec2f3b98cb2b7a649b69d24abaf5c130: Bug 1286464 part.13 ContentEventHandler::OnQueryTextRectArray() should guess a line breaker's rect with previous character's rect if it's available r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 05 Aug 2016 14:31:37 +0900 - rev 400384
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1286464 part.13 ContentEventHandler::OnQueryTextRectArray() should guess a line breaker's rect with previous character's rect if it's available r=smaug This is hack for returning better rect for a line breaker caused by non-<br> element. E.g., if a block frame causes a line break, after the last visible character is the best position, i.e., there is |<p>ABC</p><p>DEF</p>| and the caret is after "C", querying next character's rect should be computed with "C"'s rect, rather than computed with next <p> element's border rect. MozReview-Commit-ID: 7nXt74GGpNf
1ec72fa73a420eb8c0b585d5d50fedfe1cc4bfd5: Bug 1286464 part.12 ContentEventHandler::GetFirstFrameHavingFlatTextInRange() should return only frames whose content causes text r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 21 Jul 2016 17:45:17 +0900 - rev 400383
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1286464 part.12 ContentEventHandler::GetFirstFrameHavingFlatTextInRange() should return only frames whose content causes text r=smaug If it returns frames which don't cause text, the caller needs complicated loop. So, it should return only frames which causes some text. MozReview-Commit-ID: 9gny0w1PUMa
f0d008a58140f67826ced14e41a1a02c0dbbc411: Bug 1286464 part.11 nsTextFrame::GetCharacterRectsInRange() shouldn't compute character rect at the first character in next nsTextFrame r=jfkthame
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 21 Jul 2016 16:24:37 +0900 - rev 400382
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1286464 part.11 nsTextFrame::GetCharacterRectsInRange() shouldn't compute character rect at the first character in next nsTextFrame r=jfkthame nsTextFrame::GetCharacterRectsInRange() handles a character at the end offset of its content as in it. However, it causes odd result when the caller wants first text rect in the next nsTextFrame. E.g., if end of query range is at the next nsTextFrame's first character, currently, it returns the last character as in same line. So, it should stop handling next frame's first character as in it. MozReview-Commit-ID: 7WteerisrZp
cbd5db26007a00adeebdcaba0b3a7e64cec02f7f: Bug 1286464 part.10 ContentEventHandler::OnQueryTextRectArray() should append same rects for following characters of a line breaker in nsTextFrame r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 05 Aug 2016 14:06:30 +0900 - rev 400381
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1286464 part.10 ContentEventHandler::OnQueryTextRectArray() should append same rects for following characters of a line breaker in nsTextFrame r=smaug If line breakers in a text node works as is, e.g., |white-space: pre;| is specified, we need to handle line breakers in text frames too. This patch handles "\n" in text nodes same as line breakers caused by some elements. MozReview-Commit-ID: JmXesusFxzR
7d958446932b9a7d489da6bd3a22821b4cd40810: Bug 1286464 part.9 ContentEventHandler::OnQueryTextRectArray() shouldn't append same rect for following character of a lien breaker when the query range starts from middle of the line breaker r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 05 Aug 2016 13:53:08 +0900 - rev 400380
Push 26138 by gszorc@mozilla.com at Sat, 13 Aug 2016 03:04:36 +0000
Bug 1286464 part.9 ContentEventHandler::OnQueryTextRectArray() shouldn't append same rect for following character of a lien breaker when the query range starts from middle of the line breaker r=smaug If the query range starts middle of a line breaker, i.e., "\r[\n", ContentEventHandler::OnQueryTextRectArray() does not need to (in other words, should not) append same rect anymore. This patch checks if the range starts middle of a line breaker and in such case, skip to append same rect. MozReview-Commit-ID: H5gdtAakGcP
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip