Closed Bug 1053185 Opened 10 years ago Closed 10 years ago

Missing preferences for Mulet (dist, package)

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
2.1 S4 (12sep)

People

(Reporter: gerard-majax, Assigned: gerard-majax)

References

Details

(Keywords: regression, Whiteboard: [systemsfe])

Attachments

(5 files, 4 obsolete files)

pref reading ordering
1.20 KB, text/plain
Details
pref reading ordering after moving b2g.js
1.11 KB, text/plain
Details
duplicated components
24.79 KB, text/plain
Details
Fix preferences installation and packaging for Mulet r=mshal
1.82 KB, patch
mshal
: review+
Details | Diff | Splinter Review
find-try-errors.sh
1.24 KB, text/x-sh
Details 
This was working, but now it's not working anymore. When starting Mulet, we get the default Firefox starting page.
It has originaly being done in bug 1000122.
Blocks: 1000122
Even the firstrun pref is properly defined but it's like it has no effect.
(In reply to Alexandre Poirot [:ochameau] from comment #3)
> It might be interesting to trace:
> http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.
> js#4953

Well all I find for now shows that SOME prefs are pulled from b2g.js and some are from firefox.js ; namely, |browser.startup.homepage| is "about:home" (Firefox) while |browser.viewport.scaleRatio| is properly defined from B2G.
And hacking:
> mv obj-mulet/dist/bin/defaults/pref/b2g.js obj-mulet/dist/bin/browser/defaults/preferences/

Seems to do the job.
Whiteboard: [systemsfe]
Attached file pref reading ordering — 
This is the order in which pref files are read.
And we can see what happens after moving the b2g.js file as documented earlier.
Attached patch Define DIST_SUBDIR for Mulet (obsolete) — — Splinter Review 
Due to the way preferences are read, we need to have firefox.js and
b2g.js to be living together in the same directory, as exposed in bug
1053185 comment 7. Doing so will ensure that the proper precedence is
given to the pref and in the end we ensure that the preferences we
redefine in b2g.js indeed overwrite those defined by firefox.js. To do
so, we need to define DIST_SUBDIR to browser for Mulet so that rules.mk
will pick up the proper preferences directory.
With the patch proposed in attachment 8475183 [details] [diff] [review], I don't have any issue now :)
Flags: needinfo?(poirot.alex)
As soon as a build peer is fine with such hack...
but there might be better ways to ensure that b2g/app/b2g.js is processed after browser/app/profile/firefox.js.

For example I don't know if the order between b2g/ and browser/ is important over here:
http://mxr.mozilla.org/mozilla-central/source/b2g/dev/app.mozbuild#20

Or if there is some more magic to do in this Makefile:
http://mxr.mozilla.org/mozilla-central/source/b2g/dev/app/Makefile.in
Flags: needinfo?(poirot.alex)
Flags: needinfo?(mshal)
(In reply to Alexandre Poirot [:ochameau] from comment #10)
> As soon as a build peer is fine with such hack...
> but there might be better ways to ensure that b2g/app/b2g.js is processed
> after browser/app/profile/firefox.js.
> 
> For example I don't know if the order between b2g/ and browser/ is important
> over here:
> http://mxr.mozilla.org/mozilla-central/source/b2g/dev/app.mozbuild#20
> 
> Or if there is some more magic to do in this Makefile:
> http://mxr.mozilla.org/mozilla-central/source/b2g/dev/app/Makefile.in

I played already with the add_tier() ordering and it had no impact.
(In reply to Alexandre Poirot [:ochameau] from comment #10)
> As soon as a build peer is fine with such hack...

The hack you're referring to is setting DIST_SUBDIR to browser, correct? I think it's fine - it fits in with how we use DIST_SUBDIR elsewhere in moz.build files, and given how mulet operates we have to expect this sort of overlap between browser/b2g.

> but there might be better ways to ensure that b2g/app/b2g.js is processed
> after browser/app/profile/firefox.js.

I don't have another solution to suggest off-hand, but if you want me to dig into it further let me know.
Flags: needinfo?(mshal)
Comment on attachment 8475183 [details] [diff] [review]
Define DIST_SUBDIR for Mulet

Michael, since you are fine with this way of doing, I'm asking review.

Pending try is at https://tbpl.mozilla.org/?tree=Try&rev=671ee5ec408b
Attachment #8475183 - Flags: review?(mshal)
Attachment #8475183 - Flags: review?(mshal) → review+
Looks like the try is green: https://tbpl.mozilla.org/?tree=Try&rev=671ee5ec408b :)
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/56606aa26f45
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S3 (29aug)
This patch broke mulet's package so that gaia doesn't work anymore when running mulet out of the tar.bz2 package...
I don't really know why... I see various exception about xpcom being registered twice, and also some exception about mozSettings not being available.

We should back this out as having working packages is more important than having gaia being automagically opened.
(In reply to Alexandre Poirot [:ochameau] from comment #18)
> This patch broke mulet's package so that gaia doesn't work anymore when
> running mulet out of the tar.bz2 package...
> I don't really know why... I see various exception about xpcom being
> registered twice, and also some exception about mozSettings not being
> available.
> 
> We should back this out as having working packages is more important than
> having gaia being automagically opened.

backedout in https://tbpl.mozilla.org/?rev=06e1ca1fbf24
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
In dist/firefox/omni.ja, I see a lot of stuff. Specifically, I see the duplicated components you mentionned.
Attached file duplicated components — 

    
    

    
  
So Michael, we need your help:
 - without this patch, we end up with b2g at a wrong place and it does not do its job
 - with the patch, the dist/firefox is just broken and cannot run Gaia

So I hope you can help us find a way to get the b2g.js file properly placed without having to device DIST_SUBDIR.
Flags: needinfo?(mshal)

    
    

    
  
(In reply to Alexandre LISSY :gerard-majax from comment #22)
> So Michael, we need your help:
>  - without this patch, we end up with b2g at a wrong place and it does not
> do its job
>  - with the patch, the dist/firefox is just broken and cannot run Gaia
> 
> So I hope you can help us find a way to get the b2g.js file properly placed
> without having to device DIST_SUBDIR.

I see the duplicate components in omni.ja both with and without the patch - are you sure that's related to the problem?

With the patch, can you walk me through how to reproduce the problem you're seeing?
Flags: needinfo?(mshal) → needinfo?(lissyx+mozillians)

    
    

    
  
So first, generate a Gaia profile:
> make MOZILLA_OFFICIAL=1 PRODUCTION=1 PROFILE_FOLDER=profile-mulet profile-mulet

Then, after mach build package:
> ./obj-mulet/dist/firefox/firefox -no-remote -profile ../gaia/profile-mulet -jsconsole -chrome 'chrome://b2g/content/shell.html'

Then you should reproduce the issue.
Flags: needinfo?(lissyx+mozillians) → needinfo?(mshal)

    
    

    
  
I think it would be way more helpful for Michael if you could say what is actually wrong.
Do we miss some prefs? Is there some broken js xpcom? Is there something wrong with permissions?
Saying "gaia doesn't work" isn't that helpful :/

    
    

    
  
Well the only reliable symptom we see are those you documented: not booting, mozSettings not present. Apart from this, I could not get any more clue :(

    
    

    
  
We should figure out why mozSettings isn't working/available.

    
  
Flags: needinfo?(mshal)

    
    

    
  


  
Due to the way preferences are read, we need to have firefox.js and
b2g.js to be living together in the same directory, as exposed in bug
1053185 comment 7. Doing so will ensure that the proper precedence is
given to the pref and in the end we ensure that the preferences we
redefine in b2g.js indeed overwrite those defined by firefox.js. To do
so, we need to define DIST_SUBDIR to browser for Mulet so that rules.mk
will pick up the proper preferences directory. We also have to make sure
that the B2G-specifics preferences are properly packaged otherwise the
redistribuable tarball will not boot Gaia at all.

    
    

    
  
Comment on attachment 8475183 [details] [diff] [review]
Define DIST_SUBDIR for Mulet

Obsoleted by backout.

        Attachment #8475183 -
        Attachment is obsolete: true

    
  

        Attachment #8486361 -
        Flags: review?(mshal)

    
    

    
  
Comment on attachment 8486361 [details] [diff] [review]
Fix preferences installation and packaging for Mulet r=mshal

r+ assuming try is green.

        Attachment #8486361 -
        Flags: review?(mshal) → review+

    
    

    
  
And we have a green try: https://tbpl.mozilla.org/?tree=Try&rev=57a9da471059
Keywords: checkin-needed
Target Milestone: 2.1 S3 (29aug) → 2.1 S4 (12sep)

    
    

    
  
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #36)
> Backed out for Mulet mochitest perma-fail.
> https://hg.mozilla.org/integration/b2g-inbound/rev/6b3948d3413a
> 
> https://tbpl.mozilla.org/php/getParsedLog.php?id=47704030&tree=B2g-Inbound
> https://tbpl.mozilla.org/php/getParsedLog.php?id=47704129&tree=B2g-Inbound
> https://tbpl.mozilla.org/php/getParsedLog.php?id=47704108&tree=B2g-Inbound

Looking at the other tests making use of PopupNotifications.panel, I see those are disabled on Mulet.
Flags: needinfo?(poirot.alex)

    
    

    
  


  
Due to the way preferences are read, we need to have firefox.js and
b2g.js to be living together in the same directory, as exposed in bug
1053185 comment 7. Doing so will ensure that the proper precedence is
given to the pref and in the end we ensure that the preferences we
redefine in b2g.js indeed overwrite those defined by firefox.js. To do
so, we need to define DIST_SUBDIR to browser for Mulet so that rules.mk
will pick up the proper preferences directory. We also have to make sure
that the B2G-specifics preferences are properly packaged otherwise the
redistribuable tarball will not boot Gaia at all.

    
    

    
  
New version of the patch with some test disabled, while I'm not a big fan of this.

https://tbpl.mozilla.org/?tree=Try&rev=4dd7d73409e7
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=4dd7d73409e7

I could not reproduce the other errors locally (both the crash and the error referring to acertified.com)

    
    

    
  


  
Due to the way preferences are read, we need to have firefox.js and
b2g.js to be living together in the same directory, as exposed in bug
1053185 comment 7. Doing so will ensure that the proper precedence is
given to the pref and in the end we ensure that the preferences we
redefine in b2g.js indeed overwrite those defined by firefox.js. To do
so, we need to define DIST_SUBDIR to browser for Mulet so that rules.mk
will pick up the proper preferences directory. We also have to make sure
that the B2G-specifics preferences are properly packaged otherwise the
redistribuable tarball will not boot Gaia at all.

    
    

    
  
Disabling a couple more of tests that were already disabled for B2G Desktop.

https://tbpl.mozilla.org/?tree=Try&rev=079b765f9ed5
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=079b765f9ed5

    
    

    
  
We were most likely missing many b2g specific when running tests against broken package,
I imagine you fixed many things and may have to disable many tests.
Flags: needinfo?(poirot.alex)

    
    

    
  
We might want to switch to the b2gdesktop set of mochitests, rather than the desktop set that Mulet is currently running.

    
    

    
  
(In reply to Jonathan Griffin (:jgriffin) from comment #43)
> We might want to switch to the b2gdesktop set of mochitests, rather than the
> desktop set that Mulet is currently running.

How can we do this ?

BTW I sent a new Try https://tbpl.mozilla.org/?tree=Try&rev=346ec51965f8 where I hacked removing the MOZ_DISABLE_NONLOCAL_CONNECTIONS env var.

    
    

    
  

      
      
      
      

        Attached file
          
        find-try-errors.sh
        — 
      

    


  
Small shell script to help identifying quickly the failures and the matching mochitest:
> $ sh ../find-try-errors.sh 346ec51965f8
> Failure ID 47795289:
> 	content/html/document/test/test_bug741266.html:
> 		content/html/document/test/mochitest.ini
> 	docshell/test/navigation/test_bug344861.html:
> 		docshell/test/navigation/mochitest.ini
> 
> Failure ID 47795215:
> 	layout/forms/test/test_bug478219.xhtml:
> 		layout/forms/test/mochitest.ini
> 	layout/forms/test/test_bug564115.html:
> 		layout/forms/test/mochitest.ini
> 	layout/forms/test/test_bug572649.html:
> 		layout/forms/test/mochitest.ini
> 	layout/forms/test/test_bug644542.html:
> 		layout/forms/test/mochitest.ini
> 	layout/forms/test/test_bug672810.html:
> 		layout/forms/test/mochitest.ini
> 
> Failure ID 47795021:
> 	dom/tests/mochitest/bugs/test_bug369306.html:
> 		dom/tests/mochitest/bugs/mochitest.ini
> 	dom/tests/mochitest/bugs/test_window_bar.html:
> 		dom/tests/mochitest/bugs/mochitest.ini
>

    
  
Depends on: 1066044

    
    

    
  


  
Due to the way preferences are read, we need to have firefox.js and
b2g.js to be living together in the same directory, as exposed in bug
1053185 comment 7. Doing so will ensure that the proper precedence is
given to the pref and in the end we ensure that the preferences we
redefine in b2g.js indeed overwrite those defined by firefox.js. To do
so, we need to define DIST_SUBDIR to browser for Mulet so that rules.mk
will pick up the proper preferences directory. We also have to make sure
that the B2G-specifics preferences are properly packaged otherwise the
redistribuable tarball will not boot Gaia at all.

    
  
Summary: Mulet does not open shell.html by default → Missing preferences for Mulet (dist, package)

    
    

    
  
Comment on attachment 8487001 [details] [diff] [review]
Fix preferences installation and packaging for Mulet r=mshal

Let's focus only on prefernces for this bug.

        Attachment #8487001 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 8487037 [details] [diff] [review]
Fix preferences installation and packaging for Mulet r=mshal

Let's focus only on prefernces for this bug.

        Attachment #8487037 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 8487891 [details] [diff] [review]
Fix preferences installation and packaging for Mulet r=mshal

Back to the original r+ patch

        Attachment #8487891 -
        Attachment is obsolete: true

    
    

    
  
So in fact we don't have to change anything to this patch, but it will need to wait for bug 	1066044 to be able to land: we're taking care of disabling the remaining mochitests in this bug.

    
  
Blocks: 1043699

    
    

    
  
So now that bug 1066044 made it, this one can.
This try was with both bugs landed, and was green: https://tbpl.mozilla.org/?tree=Try&rev=b1950fdbd196
Keywords: checkin-needed

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/a84683944790
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED

    
  
Blocks: 1063824

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: