1011685 - Metrofx asserts on startup in WindowsMessageLoop

Status: RESOLVED FIXED

(Firefox for Metro Graveyard :: Browser, defect)

Description

[Eklavya Mirani]

Strangely, I tried opening Metro firefox today from my debug build (updated to the head today), and it wouldn't launch at all! It would just exit the desktop mode and not launch metro firefox when I clicked Start in windows 8 touch mode. The Start menu tile also didnt do anything (Exiting silently.)

Finally got it to work after deleting the default profile in AppData\Local\Mozilla\MetroFirefox\Profiles. Is this normal?

The only change I made to my build was rebasing the reader mode patch to the latest head, which seems to be working properly after I got the browser to start.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Getting a log of the console output would probably be the first step in debugging this. I don't know if you can still do that now that it's working ok for you.

Comment 2

[Maksim Lebedev]

Some additional investigations:
I create build with sources updated on 2014-04-01 (m-c)
MetroFireFox started and worked (with issues, but worked).
Also I create build with sources update on 2014-05-01 (m-c)
MetroFireFox tryed to start and always failed.

Looks like, regression was happend May of 2014.

Comment 3

[Maksim Lebedev]

Some additional investigation about profiles:
I tryed to start version 2014-05-01 - its failed.
After it I remove profile.ini (which contains info about profiles) and try to start Metro again.
(default profile recreated at start). But MetroFireFox failed again, unfortunately.

Comment 4

[Maksim Lebedev]

Attachment: mff_fail.png

This is not a full console output, but maybe anybody can get some usefull information from attached screen about start Metro FireFox.

Comment 5

[Maksim Lebedev]

Attachment: output.txt

Some outputs from debug version FireFox were attached in output.txt

Comment 6

[Matt Brubeck (:mbrubeck)]

I don't see anything immediately obvious (to me) in the log.  I'm not sure whether the text.xml or nsHandlerService.js errors are relevant.

Bisecting to find a regression range is probably the most reliable way to find the cause of the error.  Since the error seems to be profile dependent, I suspect a change to something like sessionstore, so maybe we should search the regression range for changes in that area.

Comment 7

[Matt Brubeck (:mbrubeck)]

Also, https://hg.mozilla.org/projects/metro is a project branch for Metro development.  You can work on top of this branch if you want to avoid unexpected regressions on mozilla-central.  Merges from m-c should happen only after fixing any Metro regressions.

Comment 8

[Maksim Lebedev]

(In reply to Matt Brubeck (:mbrubeck) from comment #6)
> I don't see anything immediately obvious (to me) in the log.  I'm not sure
> whether the text.xml or nsHandlerService.js errors are relevant.
Errors with text.xml are related with Desktop FF.
(because I started it first, and only after it tryed to start Metro FF).
Maybe it related with our regression, or maybe not.
Also I can see that over 2500 leaks were happened at start Desktop FF.
> Bisecting to find a regression range is probably the most reliable way to
> find the cause of the error.  Since the error seems to be profile dependent,
> I suspect a change to something like sessionstore, so maybe we should search
> the regression range for changes in that area.
I started investigation, seems regression happened beetween 2014-04-01 and 2014-05-01.

Comment 9

[Maksim Lebedev]

(In reply to Matt Brubeck (:mbrubeck) from comment #7)
> Also, https://hg.mozilla.org/projects/metro is a project branch for Metro
> development.  You can work on top of this branch if you want to avoid
> unexpected regressions on mozilla-central.  Merges from m-c should happen
> only after fixing any Metro regressions.
Unfortunately, seems that metro branch got this regression too.
(And also the second regressions related with pointercancel event - Bug 1036985)
Looks like, many patches from m-c were copied to metro branch at the end of May 2014.
As result both branches have non-worked versions of MetroFireFox.

Comment 10

[Maksim Lebedev]

Some additional investigation:
Version at 2014-04-20 doesn't work.
Look's like, regression was happen between 2014-04-01 and 2014-04-20

Comment 11

[Maksim Lebedev]

Some additional investigation:
Version at 2014-04-10 doesn't work.
Look's like, regression was happen between 2014-04-01 and 2014-04-10

Comment 12

[Maksim Lebedev]

Some additional investigation in metro branch:
The top of code in metro branch is at date 2014-06-24. Version at this date doesn't work.
If we update repo on date 2014-04-18 and use it. This version doesn't work too.

Comment 13

[Maksim Lebedev]

Some additional investigation:
Version at 2014-04-04 starts and works.
Look's like, regression was happen between 2014-04-04 and 2014-04-10

Comment 14

[Maksim Lebedev]

Some additional investigation:

Comment 15

[Maksim Lebedev]

Some additional investigation:

changeset:   183692:115aeaefd16b
user:        Bas Schouten <[e-mail]>
date:        Sun May 18 05:16:51 2014 +0200
summary:     Bug 1009590: Deal with non-ui-thread IPDL usage on Windows. r=bent

Very strange for me that this patch have influence on fails at start up Metro FireFox.
If we change only one string - we can build version of Metro, which can starts up.
I don't know will all the behavior be good after changes, but Metro will work!

Comment 16

[Jim Mathies [:jimm]]

(In reply to Maksim Lebedev from comment #15)
> Some additional investigation:
> 
> changeset:   183692:115aeaefd16b
> user:        Bas Schouten <[e-mail]>
> date:        Sun May 18 05:16:51 2014 +0200
> summary:     Bug 1009590: Deal with non-ui-thread IPDL usage on Windows.
> r=bent
> 
> Very strange for me that this patch have influence on fails at start up
> Metro FireFox.
> If we change only one string - we can build version of Metro, which can
> starts up.
> I don't know will all the behavior be good after changes, but Metro will
> work!

What the error your seeing? Is it a build error, or something else?

Comment 17

[Jim Mathies [:jimm]]

FWIW, I have the latest metro tip building and launching on my surface pro 2.

Comment 18

[Maksim Lebedev]

Attachment: metro_crash_ver1.diff

Very strange patch, because changes in this patch cancels changes,
which were not created between 2014-04-04 and 2014-04-10

And maybe it's not a main reason, because changes are not related with profiles.
Maybe second issue (related with profiles) is still situated in sources.

I doubt about correct working with profile, but seems that Metro FF will start up after it.

TRY: https://tbpl.mozilla.org/?tree=Try&rev=1419f883bba2

Comment 19

[Maksim Lebedev]

(In reply to Jim Mathies [:jimm] from comment #16)
> What the error your seeing? Is it a build error, or something else?
Metro FF closes without any messages (I mean messages in log file and in console).

Comment 20

[Maksim Lebedev]

(In reply to Jim Mathies [:jimm] from comment #17)
> FWIW, I have the latest metro tip building and launching on my surface pro 2.
Unfortunately, I have not surface pro 2.
But crashes were happened on tree different devices of three different users.

Comment 21

[Jim Mathies [:jimm]]

let me try to reproduce this, will post back.

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8458092 [details] [diff] [review]
metro_crash_ver1.diff

Please don't ask review or feedback from so many people.

Comment 23

[Jim Mathies [:jimm]]

http://hg.mozilla.org/projects/metro/rev/f457fb348e98

Comment 24

[Maksim Lebedev]

I am confusing a bit that bug get status FIXED,
because seem the main regression was earlier and is related with profiles.
I think we need more testing at this situation.

Comment 25

[Jim Mathies [:jimm]]

(In reply to Maksim Lebedev from comment #24)
> I am confusing a bit that bug get status FIXED,
> because seem the main regression was earlier and is related with profiles.
> I think we need more testing at this situation.

If there's still an issue with profiles lets file a fresh bug since we have all sort of platform people cc'd into this one now. Metro isn't officially supported so I doubt they want to see bug spam on it.

I'm not doing active testing in both a desktop nightly and metro, so I wouldn't have noticed anything weird. (I only use metro on my tablet.) But I can do some testing if we can come up with good str.

Comment 26

[Maksim Lebedev]

I think that, if this changes resolves any issue - this changes should be landed in m-c too.

Comment 27

[Maksim Lebedev]

Some additional investigation in metro branch:
After updating latest changes in metro branch I can see very strange results during testing:
On my desktop I can run MetroFF, but If I run Windows Simulator and in this
try to start MetroFF - it doesn't not start again.

Comment 28

[Maksim Lebedev]

Some additional investigation:
Version at 2014-04-08 doesn't start up.
Look's like, regression was happen between 2014-04-04 and 2014-04-08

Comment 29

[Maksim Lebedev]

Some additional investigation:
Version at 2014-04-07 starts and works.
Look's like, regression was happen between 2014-04-07 and 2014-04-08.
But I was confusing again, that version works on Desktop and it fails on Win Simulator.
Maybe it uses different profiles maybe.

At this point we have two revision:
At this revision MetroFF works:
>changeset:   181660:fdd739afef78
>user:        John Shih <[e-mail]>
>date:        Mon Apr 07 18:22:21 2014 +0800
>summary:     Bug 986837 - Part 5: Expose MozNetworkInterface for testing. r=bzbarsky
At this revision MetroFF doesn't works:
>changeset:   185098:2587cd80a66e
>user:        Peter Van der Beken <[e-mail]>
>date:        Tue Apr 08 20:48:37 2014 +0200
>summary:     Bug 789261 - Enable WebIDL bindings for Window. r=bz.
Seems that regression was between this revision.

Comment 30

[Jim Mathies [:jimm]]

(In reply to Maksim Lebedev from comment #26)
> I think that, if this changes resolves any issue - this changes should be
> landed in m-c too.

I don't think so, part or all of metrofx are going to be removed from mc here at some point. (See bug 1039866.)

Comment 31

[Maksim Lebedev]

Look's like, regression was happen between changeset: c744c837c732 and 0c41cdec18d6.
In this case latest changes made in project/metro branch seems correct.
Now MetroFF starts up on Windows and Win.Simulator in normal state (only at project/metro)

Comment 32

[Jim Mathies [:jimm]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f4634527cd78

Comment 33

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f4634527cd78