Closed Bug 983064 Opened 6 years ago Closed 6 years ago

[Sora][Message][MMS]There isn't "x-wap-profile" in MMS log.

Categories

(Firefox OS Graveyard :: Gaia::Build, defect, P1)

Product:
Firefox OS Graveyard
Component:
Gaia::Build
Type:
defect

Tracking

(blocking-b2g:1.3+, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 unaffected, b2g-v2.0 unaffected)

Status:
RESOLVED FIXED
Project Flags:
blocking-b2g 1.3+
Tracking Flags:
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- unaffected
b2g-v2.0 --- unaffected

People

(Reporter: sync-1, Assigned: vchen)

References

Details

Attachments

(3 files, 1 obsolete file)

soul 3.5 FF
5.67 KB, application/octet-stream
Details
other phone.cap
165.87 KB, application/octet-stream
Details
https:::github.com:mozilla-b2g:gaia:pull:17478
46 bytes, text/plain
timdream
: review+
Details 
Firefox OS v1.3
 Mozilla build ID: 20140226004002
 
 Created an attachment (id=664953)
 soul 3.5 FF
 
 DEFECT DESCRIPTION:
 ->There isn't"x-wap-profile"item in log
 
  REPRODUCING PROCEDURES:
 ->Send a MMS successfully,catch a log about MMS and analyse the log.
 ->There isn't"x-wap-profile"item in log(ko).
 
 Beetle lite can't catch the data log.
 
  EXPECTED BEHAVIOUR:
 ->Should have it
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
Component: Gaia::SMS → RIL
Attached file soul 3.5 FF — 
What's the impact of this bug? What do we lose if this isn't fixed?
Flags: needinfo?(sync-1)
(In reply to Jason Smith [:jsmith] from comment #2)
> What's the impact of this bug? What do we lose if this isn't fixed?

Some operators such as DT is resgrict with these, maybe they will reject our for this.
Vance - Can you find out if this is a cert blocker?
Flags: needinfo?(sync-1) → needinfo?(vchen)
(In reply to Jason Smith [:jsmith] from comment #4)
> Vance - Can you find out if this is a cert blocker?

Yes, this will be a cert blocker since x-wap-profile is for specifying the UA Profile url. But I just discuss with  田旻 , this one should be able to fixed by partner, I am waiting for the response and will update later
Flags: needinfo?(vchen)
Over to vendcom then if it's partner related.
Component: RIL → Vendcom
Attached file other phone.cap — 
We just replace the location of x-wap-profile, but we didn't remove it. After some capturing packet, I didn't see any x-wap-profile item at all.
Just try my Geekphone with the newest 1.3 build, indeed in the MMS m-send-req the x-wap-profile header is gone. Need QA's help to double check and find the regression window

Thanks

Vance
ni for comment#9
Flags: needinfo?(jsmith)
nominate for 1.3 since this one is cert blocker
blocking-b2g: --- → 1.3?
QA,

Please check if this is a regression bug. Please test with 1.1
blocking-b2g: 1.3? → 1.3+
Component: Vendcom → RIL
Keywords: qawanted
Flags: needinfo?(jsmith)
Bevis, please help.
Assignee: nobody → btseng
Hi,

According to the implementation [1], 
the only dependency of setting x-wap-profile is that 
if vendor defines the corresponding preference of 
"wap.UAProf.url" in the default preference of the device.

It won't be included if not set.

[1] http://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/src/gonk/MmsService.js#641
Flags: needinfo?(sync-1)
Actually TCL just follow the page here to do the UAProf customization:

https://wiki.mozilla.org/B2G/MarketCustomizations#WAP_user_agent_profile

This works fine in FFOS 1.1, they are using the same wapuaprof.json, only replace the UAProf url to the correct one. So they are wondering what went wrong here...

Or this is not for MMS? 

ni Weijia here for more information
Flags: needinfo?(sync-1) → needinfo?(liweijia)
Services.prefs.getCharPref('wap.UAProf.url'); ?
We just do customization in gaia, Not sure what changed in gecko.
In gaia/apps/system/resources/wapuaprof.json
the content is 
{
  "000000": {
    "url": "http://www-ccpp.tcl-ta.com/files/ALCATELOneTouch4019X.xml"
  }
}

This is what we do in v1.1 and works fine.
Flags: needinfo?(liweijia)
We might need gaia team's help to know how this wapuaprof.json mapped to 'wap.UAProf.url'
because this logic has been available since bug 804754.
This seems more related to Gaia::System App instead:
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/operator_variant/operator_variant.js#L118
Assignee: btseng → nobody
Component: RIL → Gaia::System
It's on V1.3 branch
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #18)
> This seems more related to Gaia::System App instead:
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/
> operator_variant/operator_variant.js#L118

If it's related to that, then this isn't reproducing on 1.1. That code was introduced in 1.2.
Keywords: qawanted → regression
Hi Tim, may you have someone into this bug?
Flags: needinfo?(timdream)
Flags: needinfo?(timdream) → needinfo?(josea.olivera)
(In reply to weijia from comment #16)
> Services.prefs.getCharPref('wap.UAProf.url'); ?
> We just do customization in gaia, Not sure what changed in gecko.
> In gaia/apps/system/resources/wapuaprof.json

According to the guideline in [1], it seems that the location of customized wapuaprof.json
shall not be located in gaia/apps/system/resources/wapuaprof.json.

I just followed the steps in [1] to 
1. extra the customization archive into GAIA_DIR/distribution/ mentioned in [1].
2. add customized wapuaprof.json into the same folder and build.

Then, I can see the the UAProfile URL is correctly fetched and added into x-wap-profile in the HTTP header.

[1] https://wiki.mozilla.org/B2G/MarketCustomizations#Steps_to_Apply_Customization

> the content is 
> {
>   "000000": {
>     "url": "http://www-ccpp.tcl-ta.com/files/ALCATELOneTouch4019X.xml"
>   }
> }
> 
> This is what we do in v1.1 and works fine.
Flags: needinfo?(josea.olivera) → needinfo?(liweijia)
according to 
https://github.com/mozilla-b2g/gaia/blob/v1.3/build/applications-data.js#L404
This goes to  gaia/apps/system/resources/wapuaprof.json finally.
But It doesn't work. Can someone help me to check it step to step?
Where I can do some debug?

Thanks
Flags: needinfo?(liweijia)
Bevis, are you suggesting this is a PVOB issue and should be addressed by vendor? I thought we have confirmed that it wasn't on comment 7 to comment 11. If so please mark the bug as such.

If this is an Gaia issue, you should keep :jaoo needinfo'd.
Flags: needinfo?(btseng)
Thanks for reminding, Tim.
Set this to POVB issue instead, according to comment 22.
Status: NEW → RESOLVED
Closed: 6 years ago
Component: Gaia::System → Vendcom
Flags: needinfo?(btseng)
Resolution: --- → FIXED
POVB does not means the issue is resolved.....
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [POVB]
Status: REOPENED → NEW
This field is absent for vendor to customize.
Hence, it is normal behavior in Geekphone. :)

(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #9)
> Just try my Geekphone with the newest 1.3 build, indeed in the MMS
> m-send-req the x-wap-profile header is gone. Need QA's help to double check
> and find the regression window
> 
> Thanks
> 
> Vance
Got it, thanks for your help Bevis, I will inform our partner about the new customization way introduced since v1.2

Appreciate your time and effort on this issue

Vance
Vance, can you assign this bug to partner? Thanks
Flags: needinfo?(vchen)
Unblocking this since this is a vendor problem.
blocking-b2g: 1.3+ → ---
Hi Bevis.
  We've done the steps in the wiki. what you said about wapuaprof.json is for the input of the build.

As my comment 23. 
I'm quite sure that what I'm talking about gaia/apps/system/resources/wapuaprof.json is the output of
the build(with that input wapuaprof.json of course)

If you can't reproduce, Can you tell me more where I can check?
Thanks
Hi Weijia -

Now I figure out how to set the UAProf during the build time, lets discuss this one offline tomorrow via Skype

Thanks

Vance
Flags: needinfo?(vchen) → needinfo?(liweijia)
NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:Partner cannot customize UAProf during build time
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky): no risk
[String changes made]:
Attachment #8394018 - Flags: review?(timdream)
Attachment #8394018 - Flags: approval-gaia-v1.3?(fabrice)
Comment on attachment 8394018 [details] [review]
https:::github.com:mozilla-b2g:gaia:pull:17367

Thanks. The errors seems unrelated. I have restarted Travis-CI to make sure.
Attachment #8394018 - Flags: review?(timdream) → review+
leave-open this bug since vendor should still need to confirm it's fixed on their side after Vance's patch is landed.
Keywords: leave-open
Thanks all for your help. It works on our side.
Flags: needinfo?(liweijia)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #34)
> Comment on attachment 8394018 [details] [review]
> https:::github.com:mozilla-b2g:gaia:pull:17367
> 
> Thanks. The errors seems unrelated. I have restarted Travis-CI to make sure.

Thanks, but still looks like fail on Travis....
Sounds like we're back to claiming this is a bug on our side, so moving back to 1.3+. Looks like comment 36 confirms this patch works.
blocking-b2g: --- → 1.3+
Component: Vendcom → Gaia
Keywords: leave-open
Whiteboard: [POVB]
Assignee: nobody → vchen
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #33)
> Created attachment 8394018 [details] [review]
> https:::github.com:mozilla-b2g:gaia:pull:17367
> 
> NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to
> better understand the B2G approval process and landings.
> 
> [Approval Request Comment]
> [Bug caused by] (feature/regressing bug #):
> [User impact] if declined:Partner cannot customize UAProf during build time
> [Testing completed]:
> [Risk to taking this patch] (and alternatives if risky): no risk
> [String changes made]:

Vance, can you please help fill all the above details ? Thanks !
Flags: needinfo?(vchen)
Comment on attachment 8394018 [details] [review]
https:::github.com:mozilla-b2g:gaia:pull:17367

clearing the approval request since it's a blocker
Attachment #8394018 - Flags: approval-gaia-v1.3?(fabrice)
(In reply to bhavana bajaj [:bajaj] from comment #39)
> (In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #33)
> > Created attachment 8394018 [details] [review]
> > https:::github.com:mozilla-b2g:gaia:pull:17367
> > 
> > NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to
> > better understand the B2G approval process and landings.
> > 
> > [Approval Request Comment]
> > [Bug caused by] (feature/regressing bug #):
> > [User impact] if declined:Partner cannot customize UAProf during build time
> > [Testing completed]:
> > [Risk to taking this patch] (and alternatives if risky): no risk
> > [String changes made]:
> 
> Vance, can you please help fill all the above details ? Thanks !

Sure, update again:

[Approval Request Comment] 
[Bug caused by] (feature/regressing bug #):
Unnecessary file extension ".json" caused the predefined UAProf cannot be loaded successfully during build time
[User impact] if declined:Partner cannot customize UAProf during build time
[Testing completed]: Just remove the file extension .json, no need to add test
[Risk to taking this patch] (and alternatives if risky): no risk
[String changes made]:None
Flags: needinfo?(vchen)
Component: Gaia → Gaia::Build
Attachment #8394018 - Attachment is obsolete: true
Hi Tim -

I close my previous pull request and submit a new one, this time everything looks good on Travis, could you kindly help to review again my patch?

Thanks

Vance
Attachment #8395249 - Flags: review?(timdream)
Flags: needinfo?(timdream)
Comment on attachment 8395249 [details]
https:::github.com:mozilla-b2g:gaia:pull:17478

Yeah it looks fine. Thanks.
Attachment #8395249 - Flags: review?(timdream) → review+
Flags: needinfo?(timdream)
Flags: in-moztrap?
Flags: in-moztrap? → in-moztrap-
See Also: → 1108445
You need to log in before you can comment on or make changes to this bug.