606109 - build fails with --disable-ogg --disable-wave

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[pimiento]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20101021 Gentoo Namoroka/3.6.9
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20101021 Thunderbird/3.1.4

Thunderbird do not build on my Gentoo GNU/Linux from official ebuild

Reproducible: Always

Steps to Reproduce:
1. emerge thunderbird
2. build is crash

Comment 1

[Ludovic Hirlimann [:Usul]]

Can you give us a stack trace ?

Comment 2

[pimiento]

It is just don't build. There are build.log: http://paste.pocoo.org/show/278317/

Comment 3

[Jory A. Pratt [:anarchy]]

by passing the distro is completely unacceptable IMO. I am aware that a small group of users is having an issue with current builds. You should check downstream bugzilla and cc yourself there, Ludovic feel free to close I will open a bug if appropriate when the issue is found.

Comment 4

[Jory A. Pratt [:anarchy]]

Attachment: Missing idef MOZ_MEDIA

Please assign for review this will address the bug.

Comment 5

[Jory A. Pratt [:anarchy]]

This is only gonna effect 1.9.2 branch, mozilla-central is already using proper ifdef's for media.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 485019 [details] [diff] [review]
Missing idef MOZ_MEDIA

Ehsan should review this since he added that code.
It is not clear to me whether we should allow
progress and loop also in TB even if it doesn't really support those elements.

Comment 7

[Jory A. Pratt [:anarchy]]

We have addressed it with patch in gentoo, this is really only gonna be seen by those who disable ogg/wave support. I will continue to track the progress of this report, gentoo is out of here in terms of it being the culprit.

Comment 8

[(no longer active)]

Comment on attachment 485019 [details] [diff] [review]
Missing idef MOZ_MEDIA

r=me, sorry for breaking things in the first place.

Comment 9

[(no longer active)]

(In reply to comment #6)
> It is not clear to me whether we should allow
> progress and loop also in TB even if it doesn't really support those elements.

With those #ifdef'ed out, we'll filter those elements out in the sanitizing fragment sink.

Comment 10

[(no longer active)]

Comment on attachment 485019 [details] [diff] [review]
Missing idef MOZ_MEDIA

This needs to land on trunk first.

Comment 11

[Jory A. Pratt [:anarchy]]

(In reply to comment #10)
> Comment on attachment 485019 [details] [diff] [review]
> Missing idef MOZ_MEDIA
> 
> This needs to land on trunk first.

The first part is only relevant part of the patch for trunk, refer to 

http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsContentSink.cpp#1882

loop is already handled via MOZ_MEDIA ifdef

Comment 12

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

I'm confused. "progress" is nothing to do with MOZ_MEDIA. It's an HTML5 interactive element.

Comment 13

[Jory A. Pratt [:anarchy]]

(In reply to comment #12)
> I'm confused. "progress" is nothing to do with MOZ_MEDIA. It's an HTML5
> interactive element.

If that is the case Robert, then http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsGkAtomList.h#1683 needs to be double checked.

Comment 14

[(no longer active)]

(In reply to comment #13)
> (In reply to comment #12)
> > I'm confused. "progress" is nothing to do with MOZ_MEDIA. It's an HTML5
> > interactive element.
> 
> If that is the case Robert, then
> http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsGkAtomList.h#1683
> needs to be double checked.

Yeah, that was why I thought that this change is correct...

Comment 15

[(no longer active)]

Comment on attachment 485019 [details] [diff] [review]
Missing idef MOZ_MEDIA

On second thought, this is the wrong thing to do.  The content sink should support these elements even if they're disabled in the build.  We should just define their respective atoms unconditionally.

Comment 16

[(no longer active)]

Attachment: Pathc (v2)

Like this.

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 489678 [details] [diff] [review]
Pathc (v2)

Strange place for progress. Put it higher up in the list, between
GK_ATOM(profile, "profile")
and
GK_ATOM(progressmeter, "progressmeter")

Comment 18

[(no longer active)]

Attachment: For check-in

Comment 19

[(no longer active)]

Attachment: For check-in

New patch, as half of this was landed in http://hg.mozilla.org/mozilla-central/rev/1d6823f0c00f.

Comment 20

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/605656b6f779

Comment 21

[timeless]

nsContentSink.cpp:1868: error: 'progress' is not a member of 'nsGkAtoms'
nsContentSink.cpp:1960: error: 'loop' is not a member of 'nsGkAtoms'

Comment 22

[Daniel Veditz [:dveditz]]

A non-default build option isn't going to "block" a release. Gentoo has already worked around it, it's fixed on trunk (although comment 21 is concerning), and the Thunderbird folks aren't asking for it so we'll "wontfix" on the branch without stronger arguments in favor.

Comment 23

[(no longer active)]

(In reply to comment #21)

Which revision are you on?

> nsContentSink.cpp:1868: error: 'progress' is not a member of 'nsGkAtoms'

<http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsGkAtomList.h#802>

> nsContentSink.cpp:1960: error: 'loop' is not a member of 'nsGkAtoms'

<http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsGkAtomList.h#515>

Comment 24

[timeless]

ehsan: i'm pretty sure i copied that because i don't like relying on pastebins for relevant data.

Comment 25

[(no longer active)]

(In reply to comment #24)
> ehsan: i'm pretty sure i copied that because i don't like relying on pastebins
> for relevant data.

What do you mean?  If this is answering comment 23, I don't know how to parse it.

Comment 26

[timeless]

Ehsan: trying again.

Bugs should be able to stand alone. Relying on third party paste bins for critical elements of a bug report -- especially what's actually broken (the symptoms) isn't cool.

To enable people reading a bug report to understand what was fixed, someone needs to put what was broken into the bug, that was missing from comment 0..comment 20. It's hidden in a paste.pocoo.org link which may or may not last (third party sites are known to die).

The changes I made for comment 21 -- https://bugzilla.mozilla.org/show_activity.cgi?id=606109  are in an effort to provide a meaningful bug summary and a meaningful bug description so that someone searching for bugs about problems can understand what was actually broken and thus understand why a given changeset actually fixed a given bug.

If this is unclear, please contact me via another means. I'm unlikely to be reading bugzilla in the future.