99457 - Support CSS3 'word-wrap' property (breaks long lines)

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, enhancement)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

With bug 22022 fixed, things look much better for view source when wrap is on.

However, it would be great if we didn't have to scroll horizontally at all.  
Bugzilla's main page is a great example of this with a huge URL right in the
middle of the page (View Bugs Already Reported Today). Scrolling horizontally to
see the whole URL defeats the purpose of the wrap IMO.

Doron asked me to CC some people from 22022.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Should -moz-pre-wrap break up long lines?  I don't think it should, any more
than 'white-space: normal' should.  I think this would also break other uses of
-moz-pre-wrap (e.g., textareas and plaintext mail compose), and it would also
probably differ from the description in the CSS3 spec, which I hope will include
a value equivalent to -moz-pre-wrap.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And, FWIW, this is a Layout bug, and requires perhaps nontrivial implementation
work there.  Right now the values of 'white-space' can be put in a simple grid:

'normal'          'nowrap'
'-moz-pre-wrap'   'pre'

and you're suggesting that the grid should look like:

                  'normal'          'nowrap'
'-moz-pre-wrap'                     'pre'

which suggests to me that what you really want is a new value, or perhaps two
new values, rather than a change to '-moz-pre-wrap'.

Comment 3

[rbs]

This bug looks like another bug that will be sitting here dormant (like the 
recently fixed bug 22022 -- note the low number). So if someone is interested to 
pick up the torch, here are some starting points:
- you will need to hack a new value (since -moz-pre-wrap has other uses) 
- you will need to handle a new mode for the linebreaker/wordbreaker so that 
breaking can occur with other characters such as '&' (like Nav4.x when pasting a 
long url in bugzilla comments). See nsTextTransformer.cpp which relies on
nsILineBreaker/nsIWordBreaker which are where to really effect the changes
while making sure not to break words unnecessarily (especially intl words). The 
core layout code itself won't need major changes except to append your new wrap 
value in the appropriate places where wrapping is tested, but note that it will 
make view-source with wrapping even slower because more words would have to be 
measured.

(PS: I am often amazed at the RFEs pertaining to view-source.)

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

I have no problem with a totally new value(s). Maybe this bug really should be
changed to reflect that. No idea with what it would be called though.

My point is that if wrap is on, it seems stupid to still have to scroll
horizontally, regardless of the way the W3C defined CSS values handle it.  Many
word processing programs wrap long lines and it makes a lot of sense to me.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Note that maybe this wrap value could be used for textareas.... this would solve
the "NS and IE soft wrap in the middle of a word in textareas" bugs we have
filed (I can dig up bug #s if need be).

Comment 6

[Hixie (not reading bugmail)]

As I understand it, btw, there are two possible keywords that should be supported
here. One should forget about doing word wrapping, but wrap at the end of the 
line whatever happens, a bit like with overflow on a console, and the second 
should wrap as normal *except for words longer than the line*, for which it 
should break the word at the end of the line.

   +-------------+
   |This is an ex|
   |ample of the |
   |first type, w|
   |ith each wrap|
   |ped word cut |
   |off...       |
   +-------------+
   +------------+
   |...and this |
   |is an       |
   |example of  |
   |the second  |
   |type, with  |
   |an          |
   |eeextrrreeee|
   |emmely long |
   |word.       |
   +------------+

The first would be used for a forced wrap <pre>, presumably, and the second would
be used for Chatzilla, again presumably.

When implementing this, it might be wise to implement it as four separate axes, 
as this is roughly how CSS3 will probably approach it:

   'wrap-option':
      no-wrap | wrap | emergency | width

   'linefeed-treatment':
      auto | ignore | preserve | treat-as-space | treat-as-zero-width-space

   'space-treatment':
      ignore | preserve | ignore-if-before-linefeed | ignore-if-after-linefeed | 
      ignore-if-surrounding-linefeed
   'white-space-treatment':       preserve | collapse
The 'white-space' keywords would then map as follows:

white-space wrap-option linefeed-treatment space-treatment white-space-treatment  
normal      wrap        auto               preserve        collapse
nowrap      no-wrap     auto               preserve        collapse
pre         no-wrap     preserve           preserve        preserve-m-p-w (1) 
wrap        preserve           preserve        preserve
-m-... (2)  emergency   preserve           preserve        preserve
-m-... (3)  width       preserve           preserve        preserve
...where (1) is -moz-pre-wrap, our existing extension, (2) is the extension
required for Chatzilla (as I understand it) and (3) is the extension required for
breaking <pre> blocks at the width, regardless of word wrapping.

Comment 7

[Hixie (not reading bugmail)]

(speaking of wrapping, I guess something is awry with this build...)

Comment 8

[Boris Zbarsky [:bzbarsky]]

*** Bug 146703 has been marked as a duplicate of this bug. ***

Comment 9

[Boris 'pi' Piwinger]

*** Bug 146741 has been marked as a duplicate of this bug. ***

Comment 10

[Boris Zbarsky [:bzbarsky]]

*** Bug 147127 has been marked as a duplicate of this bug. ***

Comment 11

[Matt]

Adding self to CC and hoping to God this issue is finally fixed before a release
to general public :-)

Comment 12

[Jesse Ruderman]

dbaron: I find it annoying that Mozilla's textareas don't force-wrap long words
such as URLs.  Are you sure we can't just change the behavior of -moz-pre-wrap?

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I find it incredibly useful, since it allows pasting of long URLs into bugzilla,
which 4.x did not.

Comment 14

[Jesse Ruderman]

Mozilla should display textarea contents hard-wrapped but submit them the same
was it does now.  IE gets it right, making it easier to include links in
Slashdot comments.

Comment 15

[Hans Christian Studt]

Jesse argue that "Mozilla should display textarea contents hard-wrapped".

This comment is about long normal text and I think long URL's may be different
problem.

I will suggest that Mozilla should at least offer the possibillity to wrap text
at windows width, like some editors e.g. UltraEdit does. In order to see the
need for such a function please check out the following link and SCROLL DOWN TO
THE TEXT "Sir,I have both the cds".
http://groups.google.com/groups?q=%22Sir,I+have+both+the+cds%22&hl=en&lr=&ie=UTF-8&oe=UTF8&selm=20011205015009.0E1083FEBF%40listman.redhat.com&rnum=1

Comment 16

[David G King]

I agree with Comment #13, wrapping URL's is not fun. My eMail program does that,
and I hate having to copy and paste several times to get the entire URL into the
window.

However, as this bug is blocking v1.1 (via Bug #91662), some action is required.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This doesn't block bug 91662.

Comment 18

[rbs]

For the record, here is the proposed CSS3 spec about this feature:
http://www.w3.org/TR/2002/WD-css3-text-20021024/#text-wrapping

In the terminology of CSS3, this bug is equivalent to:
|wrap-option: emergency|

Comment 19

[Christopher Hoess (gone)]

add CSS3 property to summary, reassign

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 232547 has been marked as a duplicate of this bug. ***

Comment 21

[Anne (:annevk)]

The CSS3 module where 'wrap-option' is in, is now CR. If we want to solve these
issues, we need to support it according to the specification.

Comment 22

[Brian 'netdragon' Bober]

This would be useful to use in place of wrap=hard on Bugzilla someday (bug 11901)

Comment 23

[Brian 'netdragon' Bober]

Looking at the spec longer, I don't know if this will replace wrap=hard. Will it?

http://www.w3.org/TR/css3-text/#wrap-option

The information here is confusing. Does wrap insert hard breaks or not?

Comment 24

[Anko]

(In reply to comment #23)
> Looking at the spec longer, I don't know if this will replace wrap=hard. Will it?
> 
> http://www.w3.org/TR/css3-text/#wrap-option
> 
> The information here is confusing. Does wrap insert hard breaks or not?

wrap is an attribute of a textarea.  

This bug is about creating/implementing a new css attribute, that would apply to
all elements. Totally different things.

Comment 25

[Brian 'netdragon' Bober]

There are no such things as css attributes. They are called properties.
Attributes are for HTML tags. And I know what I was asking about. If you do not
know the answer to the question I seek an answer for, please don't respond. If
you have questions about what I mean in my comment, then email me privately.

Comment 26

[Ernest Cline]

(In reply to comment #23)
> Looking at the spec longer, I don't know if this will replace wrap=hard.
> Will it?
> 
> http://www.w3.org/TR/css3-text/#wrap-option
> 
> The information here is confusing. Does wrap insert hard breaks or not?

The 'wrap-option' property, like all W3 CSS properties, is only intended to
control the presentation of content, not what goes into the content itself.

My interpretation of how the 'wrap-option' property and the <textarea> wrap
attribute should interact is as follows:

1) The default value of 'wrap-option' for a <textarea> should depend upon the
value of its wrap attribute:
  textarea[wrap=off] { wrap-option: no-wrap }
  textarea[wrap=soft] { wrap-option: wrap }
  textarea[wrap=hard] { wrap-option: wrap }

2) Whether rendered line breaks are transmitted upon submittal as line break
characters is dependent upon the value of the wrap attribute.  If wrap is off or
soft, rendered line breaks that may be generated to wrap the line in accord with
the wrap-option property are not transmitted.  If wrap is hard, such rendered
line breaks are transmitted.

Thus, the wrap-option CSS property in my opinion does not replace the <textarea>
wrap attribute.

Comment 27

[Hixie (not reading bugmail)]

http://www.whatwg.org/specs/web-forms/current-work/#extensions3

Comment 28

[Brian 'netdragon' Bober]

Ernest: Thanks. Yes, that does makes sense, sorta. So perhaps the linefeeds are
CSS generated content that apply only for presentation. Maybe I misintrepreted
Hixie's test on http://www.hixie.ch/tests/evil/mixed/wraptextarea.html to mean
that the formatting applied from the CSS property white-space (and other CSS
properties) would also be submitted with the form. It seems like the same sort
of thing. Argh, everything within the text module seems to make sense until you
start talking about forms.

I think there should be some note on http://www.w3.org/TR/css3-text/ saying that
these properties don't apply to what's submitted and to use the Web Forms
recommendation instead for that purpose.

Hixie: Thank you for the link. It seems like that's what we are looking for.

Comment 29

[Len Weisberg]

In response to comment #16:
> I agree with Comment #13, wrapping URL's is not fun. My eMail program 
> does that,  and I hate having to copy and paste several times to get 
> the entire URL into the window.

Thanks to Akkana Peck, I am among the few who know about the following
obscure incantation:

    user_pref("editor.singleLine.pasteNewlines", 3);

If this were made less obscure, there would be one less argument in
favor of preserving long lines.

Comment 30

[Phil Ringnalda (:philor)]

*** Bug 278374 has been marked as a duplicate of this bug. ***

Comment 31

[Jaime Mitchell (use [e-mail] for email)]

*** Bug 295376 has been marked as a duplicate of this bug. ***

Comment 32

[Károly Gossler]

http://www.w3.org/TR/css3-text/#changes :
"The 'wrap-option'  property has been replaced by the 'text-wrap' and
'word-break' property."

http://www.w3.org/TR/css3-text/#text-wrap
http://www.w3.org/TR/css3-text/#word-break

Comment 33

[Ria Klaassen (not reading all bugmail)]

*** Bug 332445 has been marked as a duplicate of this bug. ***

Comment 34

[fantasai]

No, actually, it's been replaced with the word-wrap and text-wrap properties.
For this bug report it seems word-wrap is wanted.

http://www.w3.org/TR/css3-text/#word-wrap
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/wordwrap.asp

Comment 35

[Stuart Morgan]

*** Bug 349142 has been marked as a duplicate of this bug. ***

Comment 36

[Dave Townsend [:mossop]]

*** Bug 355855 has been marked as a duplicate of this bug. ***

Comment 37

[Ria Klaassen (not reading all bugmail)]

*** Bug 361141 has been marked as a duplicate of this bug. ***

Comment 38

[Syophone]

Well, although CSS Text Level 3 is in Working Draft stage, are we able to do something with 'word-break' and 'word-wrap' without extensions?

Comment 39

[WulfTheSaxon [:Wulf]]

Shouldn't this be marked parity-IE6?

See http://www.456bereastreet.com/archive/200704/how_to_prevent_html_tables_from_becoming_too_wide/

---

@oueki

I believe what you're asking is whether it can be implemented in Firefox before it becomes a recommendation? If so, the answer is yes. It can be implemented as -moz-word-wrap. Take a look at -moz-outline, etc.

Comment 40

[Cesar Eduardo Barros]

Just a heads-up: MediaWiki is now using word-wrap: break-word on its diff display (see http://bugzilla.wikimedia.org/show_bug.cgi?id=1438#c12 and http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/diff.css?r1=22227&r2=22226&pathrev=22227).

Comment 41

[Syophone]

(In reply to comment #39)
> I believe what you're asking is whether it can be implemented in Firefox before
> it becomes a recommendation? If so, the answer is yes. It can be implemented as
> -moz-word-wrap. Take a look at -moz-outline, etc.

Yes, I think it's easy to be implemented them as '-moz-word-wrap' and '-moz-word-break' for Firefox.
(But it won't be implemented them before Fx 4.0, even 5.0, I afraid.)
They are important for textareas and all the block elements.

Comment 42

[Syophone]

Who can implemented them as '-moz-word-wrap' and
'-moz-word-break'?

Comment 45

[Rasmus L. Knabe]

This bug has been running since 2001 - why isen't it fixed yet?

Comment 46

[Ryan VanderMeulen [:RyanVM]]

Because nobody's deemed it high enough priority to fix it versus the other bugs needing to be fixed. If you feel that it needs to be fixed, you have the power to make it so! Download the source and hack away! I'm sure one of the layout peers would be happy to review a patch if one should come along.

Comment 47

[Rasmus L. Knabe]

Thanks for your explanation - don't know how this work. I would love to help, but sadly I doesn't have that kind of skills.

Is there some kind of community where we web developers can communicate what we need from Firefox - maybe help change the focus on what's important?

Comment 48

[Simon Montagu :smontagu]

Attachment: Patch v.1

This works quite nicely, but it produces a kind of newspaper column style break, which I'm not sure is exactly what the spec has in mind. It probably also needs some extra tweaking to avoid breaks in certain places, e.g between text and punctuation.

Comment 49

[Simon Montagu :smontagu]

Attachment: Testcase from 456.bereastreet.com with -moz-word-wrap:-moz-break-word

Comment 50

[Simon Montagu :smontagu]

Attachment: Another testcase

Comment 51

[Simon Montagu :smontagu]

Attachment: Screenshot of attachment 328988 with the patch

Comment 52

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't think this is correct. The spec says
"An unbreakable "word" may be broken at an arbitrary point if there are no otherwise-acceptable break points in the line."

But this will break at an arbitrary point even if there are otherwise-acceptable break points in the line.

Fixing that is a little tricky with our current inline layout model. You would need to modify nsLineLayout::NotifyOptionalBreakPosition to indicate the priority of the break opportunity and not allow it to override a high-priority opportunity with a lower priority opportunity. You might also need to modify the logic around DoReflowInlineFrames and its callees, where we decide whether to go ahead and place the line where it is or move it below a float. I'm not sure whether a line next to a float that has overflows and has word-wrap:break-word should break or move down.

I actually had a crack at this recently and gave up when it looked really hard. But now that I look again it's not as hard as I thought, the above approach should work.

Thanks for taking this on! It's needed.

Comment 53

[Robert O'Callahan (:roc) (email my personal email if necessary)]

BTW I think this should lose the vendor prefix. AFAIK IE and Webkit already implement this without a vendor prefix so we might as well too.

Comment 54

[Simon Montagu :smontagu]

Another thing which is probably wrong here is setting the TEXT_ENABLE_WORD_WRAP flag on the text run, rather than testing style per frame.

Comment 55

[Simon Montagu :smontagu]

(In reply to comment #52)
> I don't think this is correct. The spec says
> "An unbreakable "word" may be broken at an arbitrary point if there are no
> otherwise-acceptable break points in the line."
> 
> But this will break at an arbitrary point even if there are
> otherwise-acceptable break points in the line.

I suppose what I actually implemented was "text-wrap: unrestricted" :)

Comment 56

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #54)
> Another thing which is probably wrong here is setting the TEXT_ENABLE_WORD_WRAP
> flag on the text run, rather than testing style per frame.

Yeah definitely.

Comment 57

[Simon Montagu :smontagu]

(In reply to comment #52)
> Fixing that is a little tricky with our current inline layout model. You would
> need to modify nsLineLayout::NotifyOptionalBreakPosition to indicate the
> priority of the break opportunity and not allow it to override a high-priority
> opportunity with a lower priority opportunity.

We want that anyway for bug 389710, right?

Comment 58

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, but for bug 389710 we want something more complex. Here we just need two levels but in bug 389710 we need to choose a punctuation break over a whitespace break if the whitespace break is "too far away". I'd start with this since it's simpler and then add 389710 on top, unless you want to do them both together.

Comment 59

[Simon Montagu :smontagu]

I also notice that IE and Webkit don't display a hyphen when breaking words. To my eyes it looks a lot better with the hyphen (apart from making it much easier to implement by leveraging the existing code for soft hyphens), and the spec doesn't say anything either way, unlike with text-wrap. Do we want to be consistent with the existing implementations?

Comment 60

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes.

Comment 61

[Len Weisberg]

I agree, there should NOT be a hyphen.  It seems to me that the long word
is almost always a URL.  Whether it is re-assembled automatically when 
pasted into the location bar, or done manually, the hyphens would get in 
the way and likely lead to errors.
That may be why IE and Webkit do it without hyphens, so it's not just a 
matter of consistency.

Comment 62

[Simon Montagu :smontagu]

(In reply to comment #61)
> Whether it is re-assembled automatically when 
> pasted into the location bar, or done manually, the hyphens would get in 
> the way and likely lead to errors.

That at least is not a reason for removing the hyphens. They are only present in the display, and disappear when copying and pasting.

Comment 63

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Note that the words on CJ context don't need hyphens at breaking a word, so, we don't have to add hyphens to there. (If the automatically hyphenation is needed, we should propose a new value for word-wrap.)

Comment 64

[Robert O'Callahan (:roc) (email my personal email if necessary)]

CJK doesn't matter here since there are first-class line break opportunities between the CJK words. Auto-hyphenation is a separate issue which already has its own CSS3 property.

The reason to not show a hyphen is mainly consistency with other browsers. But also, a hyphen might be inappropriate since we have no idea what sort of text is being broken here. In the URL example, a hyphen might not cause a serious problem, but it could feel odd.

Simon, I suggest we proceed without a hyphen and if you feel strongly about it, start a discussion on www-style and see if you get can support for a hyphen from other browsers.

Comment 65

[Simon Montagu :smontagu]

Attachment: Patch v.2 (part 1)

I'm splitting the patch into two parts. This part contains all the infrastructure for the new CSS property, so as not to carry it over from version to version. It passes the mochitests in layout/style/tests.

Comment 66

[Simon Montagu :smontagu]

Attachment: Patch v.2 (part 2)

This part is the implementation, and is still somewhat w-i-p

Comment 67

[Simon Montagu :smontagu]

Attachment: Testcase without the vendor prefix

Comment 68

[Simon Montagu :smontagu]

Attachment: Screenshot of attachment 329458 with the patch

Comment 69

[Simon Montagu :smontagu]

Attachment: Testcase from 456.bereastreet.com without the vendor prefix

Comment 70

[Syophone]

Well,what about textarea using this patch?

Comment 71

[Simon Montagu :smontagu]

Attachment: CTL testcase

Tests that words don't break in mid-cluster and shaping works across word breaks.

Comment 72

[Simon Montagu :smontagu]

(In reply to comment #70)
> Well,what about textarea using this patch?

What are you asking? The patch works nicely with textarea with word-wrap: break-word specified. It doesn't add that to the default style for textarea, but maybe it should.

Comment 73

[Simon Montagu :smontagu]

AFAICT IE and Webkit both behave as if |word-wrap: break-word !important| is set for textarea.

Comment 74

[Len Weisberg]

(In reply to comment #68)
> Created an attachment (id=329459) [details]
> Screenshot of attachment 329458 [details] with the patch

This screenshot shows all "long" words starting on a new line.
Is this a requirement?
At least in this example, where the text is justfified, it results
in sometimes large amounts of empty space.

Would it be possible to allow long words to start anywhere?
It seems to me that would be preferable.  Am I missing something?

Comment 75

[Simon Montagu :smontagu]

Long words starting on a new line follows from the specification that 'an unbreakable "word" may be broken at an arbitrary point if there are no otherwise-acceptable break points in the line'. The space before the long word is an acceptable break point, so the line breaks there.

As I said already in comment 55, breaking in mid-long-word and not before it is "text-wrap: unrestricted". I plan to implement that right after this in a new bug.

Comment 76

[Simon Montagu :smontagu]

Attachment: Part 2 updated

Comment 77

[Simon Montagu :smontagu]

Attachment: Tests

Comment 78

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 329454 [details] [diff] [review]
Patch v.2 (part 1)

>-[scriptable, uuid(529b987a-cb21-4d58-99d7-9586e7662801)]
>+[scriptable, uuid(216343fe-4e61-11dd-9843-001485f1fdbb)]
> interface nsIDOMCSS2Properties : nsISupports

You should bump the IID of nsIDOMNSCSS2Properties, not nsIDOMCSS2Properties.

>+           attribute DOMString        wordWrap;
>+                                        // raises(DOMException) on setting
>+

Could you add to the end of the interface rather than the middle?


This property is already supported un-prefixed by IE, right?  Does IE support the same set of values?

Comment 79

[Simon Montagu :smontagu]

> Could you add to the end of the interface rather than the middle?

Isn't the interface sorted by category? I put it in the section marked /* CSS3 properties */

> This property is already supported un-prefixed by IE, right?  Does IE support
> the same set of values?

Yes and yes. http://msdn.microsoft.com/en-us/library/ms531186.aspx

Comment 80

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #79)
> > Could you add to the end of the interface rather than the middle?
> 
> Isn't the interface sorted by category? I put it in the section marked /* CSS3
> properties */

It's not particularly well-sorted, and the categories aren't always particularly clear.  We've been adding new ones to the end (mostly, at least).

Comment 81

[Simon Montagu :smontagu]

Attachment: Part 1, addressing David's comments

Comment 82

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This approach is good, but it needs some solid documentation describing how it works. Certainly we need some documentation for gfxBreakType.

I don't think we should have GetBreakPriority --- just use GetLastOptionalBreakPosition, which is more descriptive as well.

Other than that, it looks great.

Comment 83

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 330642 [details] [diff] [review]
Part 1, addressing David's comments

r+sr=dbaron

Comment 84

[Simon Montagu :smontagu]

Attachment: Part 2, addressing Rob's comments

Comment 85

[Simon Montagu :smontagu]

Pushed on trunk. http://hg.mozilla.org/index.cgi/mozilla-central/rev/3cf51abb4040

Comment 86

[Jim Jeffery not reading bug-mail 1/2/11]

Possible to have caused: https://bugzilla.mozilla.org/show_bug.cgi?id=447884

Comment 87

[Karl Tomlinson (:karlt)]

wordwrap-02.html now passes with Pango and
wordwrap-03.html now passes with Pango and on WINNT 6.1.
Also marked wordwrap-02.html fails on other platforms so we know when it starts to pass.
http://hg.mozilla.org/mozilla-central/rev/cd4ca07f77a8