Closed Bug 782908 Opened 10 years ago Closed 10 years ago

Update harfbuzz to current version


(Core :: Graphics: Text, defect)

Not set





(Reporter: jacek, Assigned: jacek)




(1 file, 1 obsolete file)

187.58 KB, patch
: review+
Details | Diff | Splinter Review
Attached patch fix v1.0 (obsolete) — Splinter Review
I originally intended to fix mingw-w64 compilation breakage, which was one-line change that I fixed upstream:

Meantime quite a lot changes have been made to harfbuzz and it's usually a good idea to update sooner rather than later. The attached patch updates Mozilla code to upstream 4ac4c6f2e12ddc8bf5e750671321458218b6e0c8 commit.

Here is try commit (looks green so far):
Attachment #652058 - Flags: review?(jfkthame)
Comment on attachment 652058 [details] [diff] [review]
fix v1.0

Looks fine. I was hoping to take another harfbuzz refresh soon, so thanks for doing this.

r=me, assuming the remaining tests come up green on tryserver (still waiting for Windows and Android at this point).
Attachment #652058 - Flags: review?(jfkthame) → review+
Comment on attachment 652058 [details] [diff] [review]
fix v1.0

Unfortunately, there's a reftest failure (that looks like it is indeed harfbuzz-related) on WinXP, in layout/reftests/text/arial-bold-lam-alef-1.html. So I'm retracting my r+, at least until we've investigated that. :(
Attachment #652058 - Flags: review+ → review-
After a bunch of re-triggers, that WinXP Opt reftest failed on 2 out of 10 runs. So it seems to be intermittent, but it wasn't just a one-off stray cosmic ray.

I'm not aware that this test has been failing before now, and so I suspect it's showing a genuine issue in the harfbuzz update (or an issue in our related code that happens to get exposed by the update).

The failure looks like either the U+FEFB character being mapped to the wrong glyph, or the 'fina' feature being (inappropriately) applied to U+FEFB in isolation. The fact that it's intermittent makes me wonder if perhaps there's an uninitialized value somewhere. Maybe running under valgrind would reveal a culprit, but I don't have time to try that just now.
Ouch.  OOB.  Fixed upstream.

commit bd08d5d126aa878d1dbf7bfd4b1a764c170cd9ad
Author: Behdad Esfahbod <>
Date:   Thu Aug 16 11:35:50 2012 -0400

    [OT] Fix Arabic shaper OOB access

diff --git a/src/ b/src/
index e1a2791..3e61e69 100644
--- a/src/
+++ b/src/
@@ -202,7 +202,7 @@ struct arabic_shape_plan_t
   bool do_fallback;
-  hb_mask_t mask_array[ARABIC_NUM_FEATURES];
+  hb_mask_t mask_array[ARABIC_NUM_FEATURES + 1];
Thanks for the quick investigation and fix, Behdad.

Jacek, if you could pull the new HB code including this fix, and put up a fresh patch and tryserver push, that'd be great - thanks!
Attached patch patchSplinter Review
Thanks for the quick fix! I've attached the updated patch, here is try push:
Attachment #652058 - Attachment is obsolete: true
Comment on attachment 652702 [details] [diff] [review]

r=jfkthame, as the patch looks fine and tryserver is looking happy as well... please wait for those last couple of Windows reftests to come in green before actually landing it, though. (The Linux orange is unrelated.)

FTR, this will bring us to bd08d5d126aa878d1dbf7bfd4b1a764c170cd9ad in the upstream repo.
Attachment #652702 - Flags: review+
Thanks for the review before even requesting, you own the record of my review times:) Try finished and it looks good, pushed to m-i:
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.