Closed Bug 1187322 Opened 4 years ago Closed 4 years ago

[e10s] HTML document rendering doesn't work with multi-process on OSX 10.6.8 in VirtualBox

Categories

(Core :: Graphics, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla46
Tracking Status
e10s m8+ ---
firefox43 --- wontfix
firefox44 --- wontfix
firefox45 + fixed
firefox46 --- fixed

People

(Reporter: magicp.jp, Assigned: mstange)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(2 files)

Attached image test case 1-2.png
User Agent: Mozilla/5.0 (Windows NT 6.3; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20150723030207

Steps to reproduce:

See Also: Bug 1180688

Case #1
layers.offmainthreadcomposition.enabled = true
layers.acceleration.disabled = false
- XUL documents      [OK]
- HTML documents    [NG]

Case #2
layers.offmainthreadcomposition.enabled = false
layers.acceleration.disabled = false
- XUL documents      [OK]
- HTML documents    [NG]

Case #3
layers.offmainthreadcomposition.enabled = false
layers.acceleration.disabled = true
- XUL documents      [OK]
- HTML documents    [OK]

My environment:
- Nightly 42.0a1 (20150721030212) and later
- Mac OS X 10.6.8 (Guest OS) in VirtualBox 4.3.30


Actual results:

HTML document rendering doesn't work with multi-processs on OSX 10.6.8 in VirtualBox.
Please find the attached image "test case 1-2.png"


Expected results:

HTML document rendering should work with multi-process on OSX 10.6.8 in virtual environment.
Reproduced using the following m-c build on a VM running OSX 10.7.5:
* https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015-07-24-03-02-10-mozilla-central/
Status: UNCONFIRMED → NEW
Component: Untriaged → Graphics
Ever confirmed: true
OS: Unspecified → Mac OS X
Product: Firefox → Core
Hardware: Unspecified → x86
Yes, this is not surprising.

We'll fix BasicCompositor to work in VMs before we'll be ready to ship e10s.
Whiteboard: [gfx-noted]
Version: 42 Branch → Trunk
Brad, should this be blocking e10s release, and if so, which bug?
Flags: needinfo?(blassey.bugs)
This is probably a product question.
Flags: needinfo?(blassey.bugs)
Keywords: productwanted
Sorry about sending this back to triage again. I'm renom'ing it because it's not clear in this bug, but this means that Safe Mode doesn't work with e10s on OSX.
Perhaps the solution could be different than fixing the basic compositor (e.g., don't disable OMTC in safe mode?), but we definitely need to ship with a working safe mode..
Milan, so safe mode uses the basic compositor. One question is if we still think that safe-mode needs to do it? If so, we should probably fix the basic compositor.
Flags: needinfo?(milan)
Right, what bug should this block so that it's tracked as blocking e10s?  Or is just tracking-e10s+ that's enough?

This, based on the old conversation that e10s+safe mode is a required configuration, as in, safe-mode should not turn off e10s.  If that changes, we won't care about this bug. 

In the meantime, for tracking, this should be tracked for the e10s release, so let's start with 45, as that's the newest release we can currently track.
Flags: needinfo?(milan)
Product Triage: We should be able to render web pages in safe mode before we go GA. Definitely blocks.
Keywords: productwanted
to the question of how to track, anything in a milestone is tracked for release. Putting this in m8. Milan, do you have an assignee?
Flags: needinfo?(milan)
Sounds like Markus has a beginning of a patch for this already.
Assignee: nobody → mstange
Flags: needinfo?(milan)
Duplicate of this bug: 1212858
Oh, the commit message should be "Don't require accelerated OpenGL contexts for BasicCompositor on OS X." instead.
https://reviewboard.mozilla.org/r/28965/#review25725

::: gfx/gl/GLContextProviderImpl.h:43
(Diff revision 1)
> -    CreateForWindow(nsIWidget* widget);
> +    CreateForWindow(nsIWidget* widget, bool aForceAccelerated = false);

Is it worth not having the default value for the aForceAccelerated parameter, so that the callers have to understand the options?
Ok, sure.
Comment on attachment 8701453 [details]
MozReview Request: Bug 1187322 - Don't require accelerated OpenGL contexts for BasicCompositor on OS X. r?jrmuizel

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/28965/diff/1-2/
Attachment #8701453 - Attachment description: MozReview Request: Bug 1187322 - Don't require accelerated OpenGL contexts on OS X. r?jrmuizel → MozReview Request: Bug 1187322 - Don't require accelerated OpenGL contexts for BasicCompositor on OS X. r?jrmuizel
Attachment #8701453 - Flags: review?(jmuizelaar) → review+
Comment on attachment 8701453 [details]
MozReview Request: Bug 1187322 - Don't require accelerated OpenGL contexts for BasicCompositor on OS X. r?jrmuizel

https://reviewboard.mozilla.org/r/28965/#review25943
https://hg.mozilla.org/mozilla-central/rev/c0b3b26d05cf
https://hg.mozilla.org/mozilla-central/rev/969eb8802928
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Depends on: 1236359
Markus, can we have an uplift request to aurora (45)? thanks
(In reply to Sylvestre Ledru [:sylvestre] from comment #23)
> Markus, can we have an uplift request to aurora (45)? thanks

This caused a regression (bug 1236282), so let's make sure we don't uplift until that's cleared.
Depends on: 1238539
No longer depends on: 1238539
Milan, looks like that bug 1236282 is fixed, should we uplift this one (with the other bug) or let it ride the train from 46? Thanks
Flags: needinfo?(milan)
This should be with E10S, as it messes up the safe mode.  I would prefer it just rode the trains, but Brad can comment if we need it in 45.
Flags: needinfo?(milan) → needinfo?(blassey.bugs)
(In reply to Milan Sreckovic [:milan] from comment #26)
> This should be with E10S, as it messes up the safe mode.  I would prefer it
> just rode the trains, but Brad can comment if we need it in 45.

We're testing e10s in beta 45. Does this endanger non-e10s? If not I'm leaning towards uplifting.
Flags: needinfo?(blassey.bugs)
I don't know about "endanger", but the code change applies to non-e10s, yes.  If we're going to unleash this on all of 45 beta, then we should probably uplift.
Comment on attachment 8701453 [details]
MozReview Request: Bug 1187322 - Don't require accelerated OpenGL contexts for BasicCompositor on OS X. r?jrmuizel

Requesting uplift per milan's comment 28

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: e10s beta experiment users may not get content rendered 
[Describe test coverage new/current, TreeHerder]:
[Risks and why]: 
[String/UUID change made/needed]:
Attachment #8701453 - Flags: approval-mozilla-aurora?
Whiteboard: [gfx-noted] → [gfx-noted][e10s-45-uplift]
I still haven't found a way of fixing the crashes that this patch caused, see bug 1236359. I don't recommend uplifting it at this point.
Flags: needinfo?(mstange)
Whiteboard: [gfx-noted][e10s-45-uplift] → [gfx-noted]
Comment on attachment 8701453 [details]
MozReview Request: Bug 1187322 - Don't require accelerated OpenGL contexts for BasicCompositor on OS X. r?jrmuizel

Let's take it.
Attachment #8701453 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8701453 [details]
MozReview Request: Bug 1187322 - Don't require accelerated OpenGL contexts for BasicCompositor on OS X. r?jrmuizel

This shouldn't land on 45 until bug 1241665 is ready for uplift as well.
Attachment #8701453 - Flags: approval-mozilla-aurora+ → approval-mozilla-aurora?
Depends on: 1241665
Comment on attachment 8701453 [details]
MozReview Request: Bug 1187322 - Don't require accelerated OpenGL contexts for BasicCompositor on OS X. r?jrmuizel

The other patch landed.
Attachment #8701453 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.