Updating from 04/26 nightly to 04/27 corrupts the application user interface

VERIFIED FIXED

Status

Fennec Graveyard
General
P1
major
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Anna (Waverley), Assigned: mfinkle)

Tracking

Trunk
ARM
Android

Details

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
Created attachment 528569 [details]
Corrupted application

Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:6.0a1) Gecko/20110427 Firefox/6.0a1 Fennec /6.0a1

Devices: LG Optimus 2X(Android 2.2), Google Nexus S (Android 2.3.1), HTC Desire Z (Android 2.2)

1. Update fennec from 04/26 nightly to 04/27 nightly by clicking on the check for update button from about:fennec

Actual results:
The application is installed but after launching fennec the page about:home is displayed as in the attached screenshot.

Expected results: The nightly build should be successfully installed and the application should work properly.

Note:
1. One can not pan the webpage.
2. One has to rotate the device from portrait to landscape in order for about:home to be correctly displayed.
3. If you kill the application, install an add-on or change the language (so that fennec has to restart), the behavior is the same (the one seen in the screenshot)
Looks like something we landed yesterday is causing a JS error, and that is breaking the UI.
I just built and installed using the most recent code. It installed and ran fine.

Can we try a recent tinderbox build?
Device: Nexus One

I can reproduce this after a restart of language. I can get out of this state by changing orientation
Created attachment 528580 [details] [diff] [review]
patch

I found a few issues that this patch fixes:
* Use MOZ_SAFE_BROWSING=
* Add nsUrlClassifierHashCompleter.js to package-manifest
* Make package-manifest more like desktop (removed the MOZ_SAFE_BROWSING check)
Assignee: nobody → mark.finkle
Attachment #528580 - Flags: review?(mbrubeck)
Attachment #528580 - Flags: review?(mbrubeck) → review+
tracking-fennec: --- → ?
Priority: -- → P1
Seems to work fine now with the patch above on a recent tinderbox build with http://hg.mozilla.org/mozilla-central/rev/79b0eb0dcdb7
pushed:
http://hg.mozilla.org/mozilla-central/rev/79b0eb0dcdb7
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Reporter)

Comment 7

6 years ago
I can still reproduce this issue on 04/28 nightly build.

Build Id: Mozilla /5.0 (Android;Linux armv7l;rv:6.0a1) Gecko/20110428 Firefox/6.0a1 Fennec /6.0a1 

Devices: LG Optimus 2X (Android 2.2), HTC Desire Z (Android 2.2)

Reopening the bug ...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #7)
> I can still reproduce this issue on 04/28 nightly build.
> 
> Build Id: Mozilla /5.0 (Android;Linux armv7l;rv:6.0a1) Gecko/20110428
> Firefox/6.0a1 Fennec /6.0a1 
> 
> Devices: LG Optimus 2X (Android 2.2), HTC Desire Z (Android 2.2)
> 
> Reopening the bug ...

Weird. Not seeing it on my 04/28 nightly.
(In reply to comment #8)
> (In reply to comment #7)
> > I can still reproduce this issue on 04/28 nightly build.
> > 
> > Build Id: Mozilla /5.0 (Android;Linux armv7l;rv:6.0a1) Gecko/20110428
> > Firefox/6.0a1 Fennec /6.0a1 
> > 
> > Devices: LG Optimus 2X (Android 2.2), HTC Desire Z (Android 2.2)
> > 
> > Reopening the bug ...
> 
> Weird. Not seeing it on my 04/28 nightly.

Scratch that, seeing it after language and or addon installation restart.
(In reply to comment #9)

> Scratch that, seeing it after language and or addon installation restart.

Any errors in the console?
One error, this.children.firstChild is null @ /content/tabs.xml
(In reply to comment #11)
> One error, this.children.firstChild is null @ /content/tabs.xml

That isn't fatal. I see it a lot in my desktop builds.
(In reply to comment #12)
> (In reply to comment #11)
> > One error, this.children.firstChild is null @ /content/tabs.xml
> 
> That isn't fatal. I see it a lot in my desktop builds.

OK, this isn't fatal but it was a red flag. I found that when the sessionstore restored the previous session (crashes or restarts), the sidebar was not hidden correctly. The sidebar width wasn't calculated correctly because there was no tab in the sidebar soon enough.

Restoring session adds tabs a bit later than the normal code path. I played with adding a dummy about:blank tab before restoring session and it seems to fix the error and hide the sidebar correctly.

Patch coming up
Created attachment 529045 [details] [diff] [review]
sidebar patch

The patch:
* adds a dummy tab before restoring the session
* listens for the "sessionstore-windows-restored" notification so we know the restore is finished, at which point we remove the dummy tab.
* we ignoreUndo on the dummy tab so it doesn't cause the undo UI to kick in

I tested this on desktop and found no sidebar issues during startup.
I tested on Android and it work OK for a normal start. It also worked OK for a restart after an add-on install.
Attachment #529045 - Flags: review?(mbrubeck)
Comment on attachment 529045 [details] [diff] [review]
sidebar patch

r=mrbubeck

Please add a comment explaining why the dummy tab is needed.
Attachment #529045 - Flags: review?(mbrubeck) → review+
is there a plan to get automated tests to check that version to version updating works?
(In reply to comment #16)
> is there a plan to get automated tests to check that version to version
> updating works?

Note here that the _update_ worked. The restart after the update caused the UI to not layout correctly. But even then, the app was useable.
pushed dummy tab fix with comment:
http://hg.mozilla.org/mozilla-central/rev/70c451a2a7f9
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
Verified fixed 
Mozilla/5.0 (Android; Linux armv7l; rv:6.0a1) Gecko/20110502 Firefox/6.0a1 Fennec/6.0a1
Status: RESOLVED → VERIFIED
Depends on: 656923
No longer depends on: 656923
tracking-fennec: ? → 6+
status-firefox6: --- → fixed
You need to log in before you can comment on or make changes to this bug.