Closed Bug 604090 Opened 10 years ago Closed 9 years ago

Sometimes starting Fennec just shows a black screen and you have to switch away and back to make it display

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set

Tracking

(fennec2.0b2+)

VERIFIED FIXED
Tracking Status
fennec 2.0b2+ ---

People

(Reporter: mossop, Assigned: mwu)

References

Details

Attachments

(1 file, 1 obsolete file)

STR:

1. Take the train in to work in the morning and use something like gReader Pro to catch up on feeds
2. Try to open one of the feeds in Fennec
3. Watch the "Fennec is loading" spinner
4. See the screen go black
5. Get annoyed because nothing else happens
6. Press home, open gReader Pro and tap the link again
7. See Fennec display and open the link properly in a new tab.

This seems to happen something like 90% of the time that I open Fennec from other apps
blocking2.0: --- → ?
blocking2.0: ? → ---
tracking-fennec: --- → ?
Mossop, is this a regression from yesterday?
tracking-fennec: ? → 2.0b2+
No this is something I've been seeing for maybe about a week now
im on nexus one using the 10/12 nightly, and unable to reproduce the problem.   Dave tried it again on his epic in front of me and of course it works. 

(Insert irony: Developer tries to reproduce a bug in front of a tester and it doesn't repro!)

Resolving WFM for now.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
This is still happening and it also seems to happen even when not trying to open a link. Just starting Fennec will sometimes display the black screen.

Beltzner said on IRC that he was seeing the same thing
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: Links that start Fennec do not get loaded → Sometimes starting Fennec just shows a black screen and you have to switch away and back to make it display
Indeed, saw it a bunch on the 20101017 and 20101018 nightlies, though I haven't yet on the 20101020 nightly.

You can also work around it by locking the screen and then unlocking.
OS: Mac OS X → Android
Hardware: x86 → ARM
(In reply to comment #4)
> This is still happening and it also seems to happen even when not trying to
> open a link. Just starting Fennec will sometimes display the black screen.
> 
> Beltzner said on IRC that he was seeing the same thing

Do you see this with the 20101020 nightly? We've changed how we start the process between 20101019 and 20101020.
(In reply to comment #6)
> Do you see this with the 20101020 nightly? We've changed how we start the
> process between 20101019 and 20101020.

Not yet. I'll close this as WFM or fixed by <tell me the bug number, blassey?> if I don't see it again by EOD.
Seems to be working now / can't reproduce. I'll re-open if it comes back. For reference, what's the bug number that fixed this?
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → WORKSFORME
a side effect of bug 569497 is that it changed how we start the process
Gotta re-open this. Saw it a couple of times today; feels like once the application gets into that state, it stays this way. I should note it's rarely on cold startup, only on restore after it's been a while since I've used the phone.

Happy to help debug if possible.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I just saw this again too. In my case though it only ever seems to happen when Fennec hasnt been running in a while. Restarting it manually is generally succesful. First startup in the morning usually fails though
It's possible that I'm seeing something other than beltzner as locking then unlocking doesn't repaint, however I have figured out how to reproduce. This seems to happen everytime if Android has closed Fennec in the background. If I use a task killer or something then there is no problem
Bob, are there any scenarios (not mentioned here) that have brought about the black screen on your Captivate?
Attached patch patch (obsolete) — Splinter Review
this patch will force us to create a new bitmap every time we go to the background and return.

It also adds some logging for exceptions in our surface handling code and removes the unused mSurfaceChanged..
Assignee: nobody → blassey.bugs
Status: REOPENED → ASSIGNED
Attachment #485121 - Flags: review?(mwu)
I believe this has been fixed by the patch on bug 601282. Please reopen if you have black screens with the latest nightly.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago9 years ago
Resolution: --- → FIXED
Attachment #485121 - Flags: review?(mwu)
The app shell had special handling for events received before the app shell was fully initialized. The special handling only caught the first event that was sent however, and it turns out that the first event sent early is not always the resize event anymore. It can also be a LOAD_URI event now for some reason, so maybe the webapps patch changed things. Anyway, this patch just prevents the java wrapper from sending events until we're ready. This also fixes a potential crash if an event is sent after the appshell is created but before it's initialized.
Assignee: blassey.bugs → mwu
Attachment #485121 - Attachment is obsolete: true
Status: RESOLVED → REOPENED
Attachment #485878 - Flags: review?(blassey.bugs)
Resolution: FIXED → ---
Comment on attachment 485878 [details] [diff] [review]
Notify java wrapper when we're ready to take events

I like it, much cleaner.

Can you also include removing the unused mSurfaceChanged and extra logging from the previous patch?
Attachment #485878 - Flags: review?(blassey.bugs) → review+
http://hg.mozilla.org/mozilla-central/rev/987686fe67cb
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Duplicate of this bug: 607311
OMGYES
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.