Closed
Bug 907917
Opened 11 years ago
Closed 3 years ago
Adding a new search provider then opening the customise menu in settings causes an assertion failure.
Categories
(Firefox for Android Graveyard :: General, defect, P5)
Tracking
(fennec+)
RESOLVED
INCOMPLETE
Tracking | Status | |
---|---|---|
fennec | + | --- |
People
(Reporter: ckitching, Unassigned)
Details
(Keywords: assertion)
STR: Open a debug build of Fennec. Navigate to settings->Customise. Observe the lack of explosions. Navigate to duckduckgo.com Long-tap the search input. Select "Add search provider" Select "OK" Navigate to settings->Customise again. Observe the app crashing with: "08-21 13:52:40.769: ASSERT/MOZ_Assert(14144): Assertion failure: !mAsyncExecutionThread (AsyncClose has not been invoked on this connection!), at /home/chris/Fennec/Fennec/storage/src/mozStorageConnection.cpp:497"
Comment 1•11 years ago
|
||
Does this happen with the old search management UI on aurora?
tracking-fennec: --- → ?
Updated•11 years ago
|
Assignee: nobody → ckitching
tracking-fennec: ? → 26+
Reporter | ||
Comment 2•11 years ago
|
||
(In reply to :Margaret Leibovic from comment #1) > Does this happen with the old search management UI on aurora? Yup. I can also reproduce it on release (Debug build thereof). (To be exact - this one: http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-release-android-debug/1376734458/fennec-23.0.en-US.android-arm.apk ) This fault isn't going to cause noticeable symptoms to users of non-debug builds, but does represent a programming mistake (An omission to close a resource) somewhere in the C++ code. The symptoms are slightly different with the new UI due to the way the SIGSEGV handler seems to optimistically restart the app and carry on in case of problems. This seems to lead to a Java NPE being spat out when the preferences activity attempts to resume to find that some information that once was set has now vanished. Or something. While I could investigate this, I don't think I'm the best choice of person to do so (As it's not a regression from my latest patch, nor is it in code I have thus far worked on.)
Comment 3•11 years ago
|
||
If this problem is DEBUG only, I don't think we need to track for Fx26
Reporter | ||
Comment 4•11 years ago
|
||
(In reply to Mark Finkle (:mfinkle) from comment #3) > If this problem is DEBUG only, I don't think we need to track for Fx26 Sounds sensible. Been neglecting this one since it's not obvious to fix and not that important.
tracking-fennec: 26+ → ?
Updated•11 years ago
|
tracking-fennec: ? → +
Reporter | ||
Comment 5•10 years ago
|
||
Not going to have time to look at this any time soon...
Assignee: chriskitching → nobody
Comment 7•3 years ago
|
||
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•