Closed Bug 1583336 Opened 6 months ago Closed 6 months ago

about:support is busted on GeckoView

Categories

(GeckoView :: General, defect, P2)

Unspecified
Android

Tracking

(firefox-esr60 unaffected, firefox-esr68 wontfix, firefox69 wontfix, firefox70 wontfix, firefox71 fixed)

RESOLVED FIXED
mozilla71
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- fixed

People

(Reporter: Agi, Assigned: snorp)

References

(Blocks 1 open bug, Regression)

Details

Attachments

(1 file)

In recent builds of GeckoView, about:support is busted, e.g. there's no information about Graphics.

I've bisected it and it looks like a regression from Bug 1557642: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=11921c8b4eb05f392adf4cdaf34e5698a2c1c999&tochange=90fa7d261787a5f3d69dcc5d95cfbb316f20ca7e

We need about:support to check if WebRender is enabled or not.

When I navigate to about:support in my local build I hit an assertion, not sure if that's relevant yet.

F MOZ_Assert: Assertion failure: [GFX1]: void mozilla::gl::GLContext::fGetFloatv(GLenum, GLfloat *): Generated unexpected GL_INVALID_ENUM error, at /Users/asferro/workspace/mozilla-central/gfx/2d/Logging.h:740
F MOZ_CRASH: Hit MOZ_CRASH(GFX: An assert from the graphics logger) at /Users/asferro/workspace/mozilla-central/gfx/2d/Logging.h:741

Can you get a stack for that assert?

Flags: needinfo?(agi)

Is this good enough?

mozilla::gfx::Log<1, mozilla::gfx::CriticalLogger>::WriteLog(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&) Logging.h:741
mozilla::gfx::Log<1, mozilla::gfx::CriticalLogger>::Flush() Logging.h:279
mozilla::gfx::Log<1, mozilla::gfx::CriticalLogger>::~Log() Logging.h:272
mozilla::gl::GLContext::AfterGLCall_Debug(char const*) const GLContext.cpp:2896
mozilla::gl::GLContext::fGetFloatv(unsigned int, float*) GLContext.h:1202
mozilla::WebGLContext::InitAndValidateGL(mozilla::WebGLContext::FailureReason*) WebGLContextValidate.cpp:481
mozilla::WebGLContext::CreateAndInitGL(bool, std::__ndk1::vector<mozilla::WebGLContext::FailureReason, std::__ndk1::allocator<mozilla::WebGLContext::FailureReason> >*) WebGLContext.cpp:645
mozilla::WebGLContext::SetDimensions(int, int) WebGLContext.cpp:866
mozilla::dom::CanvasRenderingContextHelper::UpdateContext(JSContext*, JS::Handle<JS::Value>, mozilla::ErrorResult&) CanvasRenderingContextHelper.cpp:221
mozilla::dom::CanvasRenderingContextHelper::GetContext(JSContext*, nsTSubstring<char16_t> const&, JS::Handle<JS::Value>, mozilla::ErrorResult&) CanvasRenderingContextHelper.cpp:179
mozilla::dom::HTMLCanvasElement::GetContext(JSContext*, nsTSubstring<char16_t> const&, JS::Handle<JS::Value>, mozilla::ErrorResult&) HTMLCanvasElement.cpp:910
mozilla::dom::HTMLCanvasElement_Binding::getContext(JSContext*, JS::Handle<JSObject*>, mozilla::dom::HTMLCanvasElement*, JSJitMethodCallArgs const&) HTMLCanvasElementBinding.cpp:288
bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) BindingUtils.cpp:3250
CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) Interpreter.cpp:458
js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) Interpreter.cpp:551
js::CallFromStack(JSContext*, JS::CallArgs const&) Interpreter.cpp:624
Interpret(JSContext*, js::RunState&) Interpreter.cpp:3113
js::RunScript(JSContext*, js::RunState&) Interpreter.cpp:424
js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) Interpreter.cpp:592
js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) BaselineIC.cpp:3229
<unknown> 0x00001a60b91e73e3
Flags: needinfo?(agi)

I just realized it might be the emulator being funny. Let me test on a real device.

Similar assert on my S10:

F MOZ_Assert: Assertion failure: [GFX1]: Shader compilation failure, cfg: features: 0xc0 multiplier: 1 op: CompositionOp::OP_OVER, at /Users/asferro/workspace/mozilla-central/gfx/2d/Logging.h:740
F MOZ_CRASH: Hit MOZ_CRASH(GFX: An assert from the graphics logger) at /Users/asferro/workspace/mozilla-central/gfx/2d/Logging.h:741

I can't seem to make the debugger work though :/ so no stacktrace.

This bug blocks rolling out Android WebRender because QA needs about:support to confirm that WebRender is enabled and working (on Google Pixel 2 devices and not on any other devices).

Blocks: wr-android
Rank: 5
OS: All → Android
Priority: -- → P2

So I think the above crash is an unrelated bug with the mac emulator, so that was a red herring.

Assignee: nobody → snorp

Selectively quoting my comments on phab:

! In D47654#1452046, @Gijs wrote:
Why is MOZ_UPDATER defined [if we don't want to show it]? That seems like it might break things in more places.

I suspect the right fix is one of:

  1. undefine MOZ_UPDATER for geckoview
  2. [...] audit other uses of MOZ_UPDATER to ensure we do the right thing on geckoview.

I don't know which it is because I don't fully understand why we currently define MOZ_UPDATER on geckoview and/or if we should.

It seems like we should clarify this in a follow-up, though I've accepted and lando'd the patch as-is as it just makes the JS consistent with the ifdefs in the markup of about:support, even if the current logic seems... confusing. :snorp, can you file a follow-up?

Flags: needinfo?(snorp)

Yeah, I agree, we shouldn't have MOZ_UPDATER at all. I filed Bug 1585667 to take care of that.

Flags: needinfo?(snorp)
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

firefox70=wontfix because we don't need to uplift this about:support fix to GV 70 Beta. WebRender will test GV 71 Nightly in Focus.

You need to log in before you can comment on or make changes to this bug.