Closed Bug 883341 Opened 11 years ago Closed 11 years ago

FirefoxOS file upload input element treats contacts as files because contacts app implements "pick" activity

Categories

(Firefox OS Graveyard :: Gaia::Contacts, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::Contacts
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:leo+, b2g18 verified, b2g-v1.1hd fixed)

Status:
RESOLVED FIXED
Project Flags:
blocking-b2g leo+
Tracking Flags:
Tracking Status
b2g18 --- verified
b2g-v1.1hd --- fixed

People

(Reporter: julienw, Unassigned)

Details

(Keywords: regression)

Attachments

(2 files)

screenshot
81.61 KB, image/png
Details
Link to Github https://github.com/mozilla-b2g/gaia/pull/10706
191 bytes, text/html
arcturus
: review+
Details
Attached image screenshot — 
STR:
* install the app "sliding puzzle" from the marketplace
* launch the app
* tap "browse"

=> the activity to choose an image starts, and shows all applications that can provide an image. The contact app is shown as "communications" which seems wrong (Bug 883334).

* tap "communications"
* wait that the contacts app starts
* choose any contact, the bug happens whether it has a photo or it hasn't

=> an empty alert is shown, and the contact is not chosen. See screenshot.

qawanted to know if that happens in v1.1.
Confirmed on 1.1. Looks like a pretty broken experience in the Contacts app. I'm guessing this is a regression.
Keywords: qawanted → regression
Changing the component to system, to me is not a problem with the communications/contacts application.

In communications we are defining the following pick activity:
"pick": {
      "filters": {
        "type": ["webcontacts/contact","webcontacts/email"]
       },
      "disposition": "inline",
      "href": "/contacts/index.html?pick",
      "returnValue": true
    }

Which defines filters webcontacts/contact and webcontacts/email

In the code for the application (in this case sliding puzzle), we invoke the activity like:

var pick = new MozActivity({
                name: "pick",
                data: {
                    type: ["image/png", "image/jpg", "image/jpeg"]
                }
            });
            pick.onsuccess = function() {
                // Create image and set the returned blob as the src
                puzzle.init(this.result.blob);
            };

So seems to me like the filter is not working properly.
Component: Gaia::Contacts → Gaia
@fabrice, am I missing something about the activity filtering here?

Thanks a lot!
Also notice that the music and video apps also appear in the activity selection
blocking-b2g: leo? → leo+
Blocking since this is a confirmed regression.
Hema, hoping you're the right person to reassign based upon functional group mapping.
Assignee: nobody → hkoka
Assignee: hkoka → dflanagan
This doesn't have anything to do with the contacts app, or, I think with the image pick activity. Setting wall paper still works.  Selecting a contact photo still works. Both of those are image picks. Attaching a photo to a MMS message still works.

Selecting a contact (a contact pick) from the SMS app works also.

The only thing that doesn't work is the 3rd-party app.

Maybe there is a bug here where 3rd party apps aren't getting the same activity behavior as built-in apps?  

Or maybe it is just a bug in the 3rd party app.

Is anyone in touch with the author of that sliding puzzle app (Cool app, by the way!)

I'd like to see the types in the pick changed to ['image/*', 'video/*'] Or just change to 'image/*' to be even simpler.

I'm going to unassign myself, since this doesn't appear to be related to the media apps in any way.  If there is a bug, it is in the system app or in gecko's activities code.  

Fabrice: (when you're back from vacation) do you know who could look at this?
Assignee: dflanagan → nobody
Flags: needinfo?(fabrice)
(In reply to David Flanagan [:djf] from comment #7)
> This doesn't have anything to do with the contacts app, or, I think with the
> image pick activity. Setting wall paper still works.  Selecting a contact
> photo still works. Both of those are image picks. Attaching a photo to a MMS
> message still works.
> 
> Selecting a contact (a contact pick) from the SMS app works also.
> 
> The only thing that doesn't work is the 3rd-party app.

More specifically, input=file actually.

> 
> Maybe there is a bug here where 3rd party apps aren't getting the same
> activity behavior as built-in apps?  

I think it's more likely an issue with input file. That's what the app is using here. I also reproduced this exact bug with my test site that uses a bunch of input file tags.

> 
> Or maybe it is just a bug in the 3rd party app.

Don't think so.

> 
> Is anyone in touch with the author of that sliding puzzle app (Cool app, by
> the way!)

We don't need to do outreach here. I can reproduce this with my test case here - http://mozilla.github.io/qa-testcase-data/webapi/filemanagement/fileUploadTest.html.

> 
> I'd like to see the types in the pick changed to ['image/*', 'video/*'] Or
> just change to 'image/*' to be even simpler.
> 
> I'm going to unassign myself, since this doesn't appear to be related to the
> media apps in any way.  If there is a bug, it is in the system app or in
> gecko's activities code.  
> 
> Fabrice: (when you're back from vacation) do you know who could look at this?

I'm going to redirect your needinfo request to the Andrea, who implemented input file support. He might have an idea why this is happening with input file specifically.
Component: Gaia → General
Flags: needinfo?(fabrice) → needinfo?(amarchesini)
Ah ha!

The sliding puzzle code attempts to work around lack of input file support in FirefoxOS and has code that explicitly uses an activity.  Now that we support input file, the explicit activity code does not get triggered, and instead the app is depending on our input file implementation.

Input file appears to just be doing a "pick" activity with no type specified, so that any app that supports pick can be opened.  Most apps that support pick return files.  But the contacts app uses a pick activity to return an contact's phone number or email address.  

This was probably a bad design. Perhaps we should have used "pick" only for files. We could change that, I suppose.  Or perhaps Andrea could change the input file implementation to filter out the fake mime types that the contacts app uses.
I'm going to change the title of this bug since Jason reports that it has to do with the file upload implementation.  Arguably, it should change to Core/DOM or something, too, but I won't do that.
Summary: [contacts] The "pick image" activity seems broken → FirefoxOS file upload input element treats contacts as files because contacts app implements "pick" activity
(In reply to David Flanagan [:djf] from comment #9)

> Input file appears to just be doing a "pick" activity with no type
> specified, so that any app that supports pick can be opened.  Most apps that
> support pick return files.  But the contacts app uses a pick activity to
> return an contact's phone number or email address.  

I somehow thought that using the contacts app would give me a contact picture ;)

I still don't understand what the empty alert box is though.
> More specifically, input=file actually.

<input type="file"> should be used with accept="image/*,video/*"
otherwise all the 'pick'-able apps will be used.

A part from that, we should find a way to remove 'communication' from the list of the pick-able apps.
I agree with David, we should use 'pick' activity just for files. Pick activity should contain a 'blob' in the answer and I don't see how a contact can be converted to a blob.

What about if communication uses 'contact' as activity name? I can propose a patch if we agree with this.
Flags: needinfo?(amarchesini)
As I said in comment 11, I would find it very cool that we could pick a contact photo. (but maybe that can be left for another bug in another version).
(In reply to Julien Wajsberg [:julienw] from comment #13)
> As I said in comment 11, I would find it very cool that we could pick a
> contact photo. (but maybe that can be left for another bug in another
> version).

Yes, but in another bug. What you are proposing is a new feature.
(In reply to Andrea Marchesini (:baku) from comment #12)
> > More specifically, input=file actually.
> 
> <input type="file"> should be used with accept="image/*,video/*"
> otherwise all the 'pick'-able apps will be used.
> 
> A part from that, we should find a way to remove 'communication' from the
> list of the pick-able apps.
> I agree with David, we should use 'pick' activity just for files. Pick
> activity should contain a 'blob' in the answer and I don't see how a contact
> can be converted to a blob.
> 
> What about if communication uses 'contact' as activity name? I can propose a
> patch if we agree with this.

I agree completely that we should use a new activity. Though, I think a verb like 'pick-contact' would be better than just 'contact'.  We need to find out what the contacts app developers think about this, though.

Cristian, Francisco, what do you think? Can we change the activity?
Flags: needinfo?(francisco.jordano)
Flags: needinfo?(crdlc)
Hi all,

Changing the contacts activity by itself it's not a big deal, but I'm worry about the side effects:

- We will need to change the apps that are using this activity, currently in the gaia apps I think it's sms and email.
- There are people that started getting familiar with the activities doing the simple example of picking a contact.

Anyway, not really blockers to perform the change if we finally decide to do it. But still prefer the idea of <input type="file"> honoring the filters, perhaps using a list of possible filter types or even creating a filter type called 'blob'. This will require more work, so will understand if we decide to do it in future versions and try to fix the blocker in the communications app.

Cheers,
F.
Flags: needinfo?(francisco.jordano)
Flags: needinfo?(crdlc)
I'm wondering if there is not a bigger issue with activities filtering. While trying to connect to a Wi-Fi captive portal, right after getting an IP address, I'm getting the activity picker for handling the link, proposing Email and Browser !
(In reply to Alexandre LISSY :gerard-majax from comment #17)
> I'm wondering if there is not a bigger issue with activities filtering.
> While trying to connect to a Wi-Fi captive portal, right after getting an IP
> address, I'm getting the activity picker for handling the link, proposing
> Email and Browser !

Nevermind, after rebuilding and ensuring correct b2g18 and gaia v1-train, I'm reproducing the reported issue but not was I was describing in the previous comment.
I/Gecko   ( 1191): -- ActivitiesService.jsm 1372256520489 Request successful. Record count: 6
I/Gecko   ( 1191): -- ActivitiesService.jsm 1372256520492 {"name":"pick","options":[{"manifest":"app://video.gaiamobile.org/manifest.webapp","icon":"app://video.gaiamobile.org/style/icons/Video.png","description":{"filters":{"type":["video/*","video/webm","video/mp4","video/3gpp","video/ogg"]},"disposition":"inline","returnValue":true,"href":"app://video.gaiamobile.org/index.html#pick"}},{"manifest":"app://wallpaper.gaiamobile.org/manifest.webapp","icon":"app://wallpaper.gaiamobile.org/style/icons/64/Wallpaper.png","description":{"filters":{"type":["image/*","image/jpeg"],"width":320,"height":480},"disposition":"inline","returnValue":true,"href":"app://wallpaper.gaiamobile.org/pick.html"}},{"manifest":"app://music.gaiamobile.org/manifest.webapp","icon":"app://music.gaiamobile.org/style/icons/Music.png","description":{"filters":{"type":["audio/*","audio/mpeg","audio/ogg","audio/mp4"]},"disposition":"inline","returnValue":true,"href":"app://music.gaiamobile.org/index.html#pick"}},{"manifest":"app://gallery.gaiamobile.org/manifes
I/Gecko   ( 1191): -- ActivitiesService.jsm 1372256520493 {"manifest":"app://video.gaiamobile.org/manifest.webapp","icon":"app://video.gaiamobile.org/style/icons/Video.png","description":{"filters":{"type":["video/*","video/webm","video/mp4","video/3gpp","video/ogg"]},"disposition":"inline","returnValue":true,"href":"app://video.gaiamobile.org/index.html#pick"}}
I/Gecko   ( 1191): -- ActivitiesService.jsm 1372256520494 {"manifest":"app://wallpaper.gaiamobile.org/manifest.webapp","icon":"app://wallpaper.gaiamobile.org/style/icons/64/Wallpaper.png","description":{"filters":{"type":["image/*","image/jpeg"],"width":320,"height":480},"disposition":"inline","returnValue":true,"href":"app://wallpaper.gaiamobile.org/pick.html"}}
I/Gecko   ( 1191): -- ActivitiesService.jsm 1372256520494 {"manifest":"app://music.gaiamobile.org/manifest.webapp","icon":"app://music.gaiamobile.org/style/icons/Music.png","description":{"filters":{"type":["audio/*","audio/mpeg","audio/ogg","audio/mp4"]},"disposition":"inline","returnValue":true,"href":"app://music.gaiamobile.org/index.html#pick"}}
I/Gecko   ( 1191): -- ActivitiesService.jsm 1372256520494 {"manifest":"app://gallery.gaiamobile.org/manifest.webapp","icon":"app://gallery.gaiamobile.org/style/icons/Gallery.png","description":{"filters":{"type":["image/*","image/jpeg","image/png"]},"disposition":"inline","returnValue":true,"href":"app://gallery.gaiamobile.org/index.html#pick"}}
I/Gecko   ( 1191): -- ActivitiesService.jsm 1372256520495 {"manifest":"app://communications.gaiamobile.org/manifest.webapp","icon":"","description":{"filters":{"type":["webcontacts/contact","webcontacts/email"]},"disposition":"inline","href":"app://communications.gaiamobile.org/contacts/index.html?pick","returnValue":true}}
I/Gecko   ( 1191): -- ActivitiesService.jsm 1372256520495 {"manifest":"app://camera.gaiamobile.org/manifest.webapp","icon":"app://camera.gaiamobile.org/style/icons/Camera.png","description":{"filters":{"type":["image/*","image/jpeg","video/*","video/3gpp"]},"returnValue":true,"disposition":"inline","href":"app://camera.gaiamobile.org/index.html#pick"}}
(In reply to Francisco Jordano [:arcturus] from comment #16)
> Hi all,
> 
> Changing the contacts activity by itself it's not a big deal, but I'm worry
> about the side effects:
> 
> - We will need to change the apps that are using this activity, currently in
> the gaia apps I think it's sms and email.
> - There are people that started getting familiar with the activities doing
> the simple example of picking a contact.
> 
> Anyway, not really blockers to perform the change if we finally decide to do
> it. But still prefer the idea of <input type="file"> honoring the filters,
> perhaps using a list of possible filter types or even creating a filter type
> called 'blob'. This will require more work, so will understand if we decide
> to do it in future versions and try to fix the blocker in the communications
> app.
> 
> Cheers,
> F.

As far as I can say, it seems the <input type="file"> element triggers this call to select the Activity:

I/Gecko   ( 1909): -- ActivitiesService.jsm 1372259820029 aMsg([object Object])={"id":"{1b416ef6-636c-455c-b230-4601d9290908}","options":{"name":"pick","data":{}},"manifestURL":null,"pageURL":"chrome://browser/content/shell.xul"}
Just changing the contacts WebActivity name so it doesn't come up at the file selector isn't a solution. Because there's nothing preventing any third party, non privileged app, to declare a pick activity on its manifest and "break" the file selector this same way. 

I think the problem is that WebActivities aren't a good choice for this kind of interaction (for any kind of interaction where you want to control somehow the valid providers). Whatever the solution is, shouldn't let a third party app to cause strange/undesired behaviors to other apps.
(In reply to Antonio Manuel Amaya Calvo from comment #21)
> I think the problem is that WebActivities aren't a good choice for this kind
> of interaction (for any kind of interaction where you want to control
> somehow the valid providers).

I don't think there can be any other kind of choice for it when you want to enable open APIs for apps to hook in. IMHO, any app using WebActivities needs to treat that interaction like user input and check that its expectations on what it receives through it are met if it has such expectations.
I agree. The problem is that in this case apps aren't using a web acivity, they're using an input of type file. And they'll get... Unexpected results.
> Just changing the contacts WebActivity name so it doesn't come up at the
> file selector isn't a solution. Because there's nothing preventing any third
> party, non privileged app, to declare a pick activity on its manifest and
> "break" the file selector this same way. 

Indeed. But currently the b2g filePicker is based on 'pick' WebActivities and we like the idea that a 3rd party apps can add new functionalities for picking files/images/etc.

Doing this, we expose the filePicker to misuse WebActivities code. This is a known issue and I don't see how we can prevent this: we cannot force apps to use 'pick' activities just for files. Probably we can write good documentation, saying that, implementing the pick-able activity support, the app will be shown in the FilePicker.
Just so that I understand correctly: if a web page uses the "accept" attribute as defined in HTML5 [1], are we filtering correctly ? ie, are we still showing the communications/ entry in that case ? If we're filtering correctly in that case, then I think we should close this bug invalid.

[1] http://www.w3.org/TR/html-markup/input.file.html
The accept filters work for a single accept filter right now. However - I'm not sure how well evangelized accept filters are being used in apps right now. So I don't think we can rely on it being specified here. Not fixing this bug anyways introduces a web compatibility problem, as this will always be present on any input=file call with no accept filters.

As such, I tend to think this is still a valid bug. If you can put a user into a state where you choose an app and open up an empty dialog, then there's something not right here. input=file on return is expecting a consistent type on return of the activity that is a supported MIME type for input=file. However, the Contacts app violates this rule right now in alignment with other pick activities, so we're inconsistent in what the caller of the activity gets back.

One potential safe fix here would be do the something like the following:

* Introduce a "pick-file" activity
* input=file will use the pick-file activity instead of pick activity
* Applicable apps (e.g. Gallery) that could make use of providing Files to input=file would implement this
** Example - Gallery can use this to follow a similar path as the pick activity to provide a File when called

The solution above solves the problem presented in the bug and is backwards compatible to keep the original pick activity the same. 

A different proposal is in alignment with what's mentioned above in a different comment - the Contacts app would implement a different activity other than pick (i.e. pick-contact). The advantage of a proposal of this is that this removes the inconsistency present in the pick activity with the Contacts app and probably is a safer fix than the above proposal mentioned. However, this risks breaking compatibility between 1.01 & 1.1, which might lead to user agent sniffing by app developers.
AFAIk activities are handled by Gecko at one point. Couldn't Gecko check that the returned object is indeed a blob ? That's probably quite late in the process.

Plus, you're right, we still don't know where that empty alert comes from. Francisco, do you know ?
(In reply to Julien Wajsberg [:julienw] from comment #27)
> AFAIk activities are handled by Gecko at one point. Couldn't Gecko check
> that the returned object is indeed a blob ? That's probably quite late in
> the process.
> 
> Plus, you're right, we still don't know where that empty alert comes from.
> Francisco, do you know ?

I'm gonna look into this
(In reply to Alexandre LISSY :gerard-majax from comment #28)
> (In reply to Julien Wajsberg [:julienw] from comment #27)
> > AFAIk activities are handled by Gecko at one point. Couldn't Gecko check
> > that the returned object is indeed a blob ? That's probably quite late in
> > the process.
> > 
> > Plus, you're right, we still don't know where that empty alert comes from.
> > Francisco, do you know ?
> 
> I'm gonna look into this

This empty dialog comes from an (yet unidentified) call to ConfirmDialog._show() with empty parameters.
The spurious call is at https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/js/contacts.js#L267

This case makes just no sense to me, what's the goal of this ?
Flags: needinfo?(alberto.pastor)
(In reply to Alexandre LISSY :gerard-majax from comment #30)
> The spurious call is at
> https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/
> js/contacts.js#L267
> 
> This case makes just no sense to me, what's the goal of this ?

Okay I think I understand what's happening here:

The 'pick' activity triggered by <input type="file"> contains no "data", hence no filtering can happen: I think that this explains why Communications is presented in the choices.

Then, the Contacts app relies on this same value to prepare the data to be fed back for the application that triggered 'pick':

      switch (ActivityHandler.activityDataType) {
        case 'webcontacts/contact':
          type = 'number';
          dataSet = theContact.tel;
          noDataStr = _('no_phones');
          selectDataStr = _('select_mobile');
          break;
        case 'webcontacts/email':
          type = 'email';
          dataSet = theContact.email;
          noDataStr = _('no_email');
          selectDataStr = _('select_email');
          break;
      }   

The value on which the switch is performed is coming from:

    get activityDataType() {
      if (!this._currentActivity) {
        return null;
      }   
  
      return this._currentActivity.source.data.type;
    },  

However, due to 'pick' from <input type="file">, this value is undefined. Hence, the empty dialog is showed, which seems to be correct from the code point of view.

Could you please help us understand the purpose of this empty dialog ? Shouldn't we pop the user a message like "Sorry we cannot export your contacts for this type of data" ?
Flags: needinfo?(bkelly)
(In reply to Andrea Marchesini (:baku) from comment #24)
> Doing this, we expose the filePicker to misuse WebActivities code. This is a
> known issue and I don't see how we can prevent this: we cannot force apps to
> use 'pick' activities just for files. Probably we can write good
> documentation, saying that, implementing the pick-able activity support, the
> app will be shown in the FilePicker.

The problem with known issues is who they're known to :). 

If I write an app where I use a WebActivity (as a client), then I should know the problems I (or users of my app) might run into. But if I write an app (which might even not be such an app but a plain web page) that uses a (I thought) well known item like input type=file then I hope for it to work as I 'know' it should. And that doesn't include a random third party app not related at all with the browser or the underlying OS coming up when the user hits 'browse'.
Hi again,

my point, again (sorry folks!), is this is not a contacts problem, is a problem with the way we handle the input field using web activities.

Any app that implements a web activity |pick| will appear there, and that doesn't mean that is suitable for handling the data that the input field needs.

Coming back to contacts, the activity is defined with the following filter:
"filters": {
        "type": ["webcontacts/contact","webcontacts/email"]
       }

Reading the definition of WebActivities from https://wiki.mozilla.org/WebAPI/WebActivities:

filters: this object should mirror data from ActivityOptions but the values for each fields can be an Array of string, a string or a regexp. An activity will be considered as able to handle an activity only if the filters are all satisfied. An array means OR for each items. If there is no filter value for a field, that means it is always satisfied

IMHO, if contacts is defining the filters |["webcontacts/contact","webcontacts/email"]| should be display in the activity chooser just if the activity was invoked using any of those filters.

And now, talking about the empty confirm :(, I think is related to the fact that we show an alert saying: 'There are no phones' when we try to pick a contact that doesnt have a phone number. That message is setup here:

https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/js/contacts.js#L249

But as you can see, we never setup the variable |noDataStr| cause of this switch:

https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/js/contacts.js#L245

And the reason that switch just accepts two cases: |webcontacts/contact| and |webcontacts/email| is again, the definition of the Activity, as we expect that activity to be invoked with this filters.

So, my proposal here is being defensive in contacts, and if we find a filter that is not any of those, just show the alert saying, 'sorry my dear friend, nothing to do there', and we cancel the activity, but again, this won't solve future problems with the input value.

Cheers!
F.
(In reply to Francisco Jordano [:arcturus] from comment #33)


[...]

> 
> So, my proposal here is being defensive in contacts, and if we find a filter
> that is not any of those, just show the alert saying, 'sorry my dear friend,
> nothing to do there', and we cancel the activity, but again, this won't
> solve future problems with the input value.
> 

From my understanding of the issue and the code, I'd agree on this ; I don't see any reason to leave an empty dialog like this, whatever the reason it gets triggered.
I broke out a separate bug for the empty dialog box issue.  See bug 888260.
Flags: needinfo?(bkelly)
Since we had a couple issues being discussed here, let me see if I can summarize the main problem and suggested solutions:

The pick activity is currently used to select both files and non-files in different apps.  These apps all define filters for the types they support; mime types for files and made-up types for non-files.  The input=file processing uses the pick activity, but does not pass a type to filter on.  The result is that all apps providing pick show up for input=file.

It sounds like proposed solutions are:

  1) Create a pick-contact activity for the one non-file case currently in use.
  2) Create a pick-file activity specifically selecting files.

Would it also be possible to:

  3) Create an "any file" filter type and have input=file specify this when using pick?  Apps providing files would then advertise this new type in addition to their specific mime types.  Or gecko could map a known set of mime types to "any file" auto-magically.
Jonas - Can I get some technical input here on what you think the right path forward here is? We've got a lot of debate across how we should fix this bug - in gecko, in gecko and gaia, in gaia - with differing approaches and tradeoffs on those approaches.
Flags: needinfo?(jonas)
What about using 'require' ? Filters can be written in this way:

  "activities": {
    "pick": {
      "filters": {
        "type": { required: true,
                  value: ["webcontacts/contact","webcontacts/email"] }
       },
       ....
    },    

In this case a generic 'pick' request will not include this app.
Sorry guys, the documentation is not good enough in this case and we should definitely improve it. I completely forgot that filters can be written as objects with properties as such as: required, values, pattern, patternFlags.

Here a good example:
https://mxr.mozilla.org/mozilla-b2g18/source/dom/activities/tests/unit/test_activityFilters.js#52
(In reply to Andrea Marchesini (:baku) from comment #38)
> What about using 'require' ? Filters can be written in this way:
> 
>   "activities": {
>     "pick": {
>       "filters": {
>         "type": { required: true,
>                   value: ["webcontacts/contact","webcontacts/email"] }
>        },
>        ....
>     },    
> 
> In this case a generic 'pick' request will not include this app.
> Sorry guys, the documentation is not good enough in this case and we should
> definitely improve it. I completely forgot that filters can be written as
> objects with properties as such as: required, values, pattern, patternFlags.
> 
> Here a good example:
> https://mxr.mozilla.org/mozilla-b2g18/source/dom/activities/tests/unit/
> test_activityFilters.js#52

Nice catch. If no one works on this before tomorrow, I'll do it.
Looks like comment 38 proposes a path forward, so I'll remove needinfo on Jonas then.
Flags: needinfo?(jonas)
(In reply to Jason Smith [:jsmith] from comment #40)
> Looks like comment 38 proposes a path forward, so I'll remove needinfo on
> Jonas then.

I'm on it to confirm that this addresses this issue. Considering the timeframe, it's a nicer fix than bug 888260 (no l10n culprit), but we might have to ensure that it does not break any interactions with other apps.
(In reply to Alexandre LISSY :gerard-majax from comment #41)
> (In reply to Jason Smith [:jsmith] from comment #40)
> > Looks like comment 38 proposes a path forward, so I'll remove needinfo on
> > Jonas then.
> 
> I'm on it to confirm that this addresses this issue. Considering the
> timeframe, it's a nicer fix than bug 888260 (no l10n culprit), but we might
> have to ensure that it does not break any interactions with other apps.

I can confirm that once the manifest is fixed this way and, of course, after a reset-gaia, the Communications app is not displayed anymore.
Comment on attachment 769374 [details]
Link to Github https://github.com/mozilla-b2g/gaia/pull/10706

Much better solution, forcing the filter to be respected :)

r+!
Attachment #769374 - Flags: review?(francisco.jordano) → review+
Component: General → Gaia::Contacts
Landed:

https://github.com/mozilla-b2g/gaia/commit/13c3bffc4fc1138175b60012b5459bc5d548e09c
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Keywords: verifyme
QA Contact: jsmith
Uplifted 13c3bffc4fc1138175b60012b5459bc5d548e09c to:
v1-train: 37381d48b45e5a37516ac6c8857ade20eb01ffa6
status-b2g18: affected → fixed
v1.1.0hd: 37381d48b45e5a37516ac6c8857ade20eb01ffa6
status-b2g-v1.1hd: --- → fixed
lgtm on 7/2 build - I'm not seeing Communications listed on any of my target test cases on http://mozilla.github.io/qa-testcase-data/webapi/filemanagement/fileUploadTest.html.
status-b2g18: fixed → verified
Keywords: verifyme
Flags: needinfo?(alberto.pastor)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: