1009271 - [Email] navigating to an inline mailto: link opens a blank white screen in browser iframe

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Tony Chung [:tchung]]

Attachment: logcat

If you click an inline mailto: email address, the prompt will first ask the user if they want to "browse to mailto:[e-mail]...", but then accepting it will just launch a blank white screen in some browser iframe.

Why is this whitescreen even available?

See screenshots and logcat attached.

Repro:
1) install master on Flame nightly
Gaia      c1a8cbaac1d921cfb50e3a2600720b75cf5afabd
Gecko     https://hg.mozilla.org/mozilla-central/rev/6f5597d4d3e3
BuildID   20140512040203
Version   32.0a1
ro.build.version.incremental=eng.cltbld.20140512.075357
ro.build.date=Mon May 12 07:54:09 EDT 2014

2) launch email and click on a email that has an email address within the body of the content
3) click that email address, and watch the screen pop up with a message asking if you'd like to "browse to URL? mailto:" link
4) click yes, and verify it opens a blank white screen
5) If you tap the X, it will then proceed to the compose email screen.  but the unecessary browser iframe is in the way.


Expected:
- skip the blank white screen, go straight to the compose email of that mailto: link

Actual:
- blank white screen with an X

Comment 1

[Tony Chung [:tchung]]

Attachment: b2g_email_mailToLink1.png

Comment 2

[Tony Chung [:tchung]]

Attachment: b2g_email_mailTolink3.png

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

This is technically a system/platform regression, but this likely merits discussion as to whether we should be using activities instead of window.open.  Since I'm face-to-face with many relevant people this week, I'll raise it with them there first rather than writing a big essay first.

Comment 4

[Tony Chung [:tchung]]

Attachment: b2g_email_mailtoLink2.png

comment 2 has the wrong attachment.  this is the correct screenshot.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

(Correcting assignee; I recommend typing ":asuth" to autocomplete to me as many other people have had the good judgement to have or have been the recipients of good judgement and have the same name as me.)

I talked with Fabrice briefly about this tonight.  Fabrice indicated we should do whatever is most appropriate for our UX needs.  (Which makes sense since we currently only whitelist http/https/mailto with rtsp desired (unless we already fixed that?)).  System-wide this potentially does impact other apps too, so I'll do some brief investigation there and maybe ping someone from the systems front end team who is in MV this week too.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

I ended up talking to people about this more.  The take-away was that the email app should switch to explicitly triggering a 'view' web activity for http/https(/rtsp) links.

And for mailto links we should probably just use our own internal mechanisms since it's arguably silly for us to trigger an activity in that case.  (Certainly we're much more likely to run afoul of weird/crazy window manager bugs.  It might become less silly when we go haida.)

Unfortunately, I don't think we can get rid of the mailto confirmation prompt unless we overhaul our handling of bubbles in the compose UI.  I can formulate a mailto link that shows a display name of "[e-mail]" but really sends the message to "[e-mail]" and the user would have to click on the bubble to see the actual email address.

At some point we used to subtly differentiate display names from email addresses via use of italics.  That has clearly gone away.

The best compose mitigation would probably be to put the compose UI into a special bubble display mode that results in the bubble displaying both the display name and the e-mail address.  While there will always be an ambiguity problem, I think displaying just enough that it becomes clear that something hinky is going on is sufficient. (ex: is foo@bar the e-mail address or is bar@baz the email address when I see: "foo@bar: bar@baz"?)  This would be far superior than us showing the mailto encoded URI which has the potential to be very opaque/confusing to the user (things can get %NN encoded, etc.) but with the upside that a user seems more likely to say yes to a mailto URI that looks like random gibberish.  (Or a heuristic I'm using a lot is whether an expert such as myself has a hope of realizing they're being phished; if I don't have a chance, then the user is probably not going to either.)

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

Er, and some of the interesting rationale for using activities was that window.open even with _blank for webpages opens things in our cookie jar.  And that is because _blank intentionally opens another window in our process space so that when our app dies/gets killed the window we opened dies with us.

Comment 8

[Jason Smith [:jsmith]]

Can we confirm this is working on 1.4?

Comment 9

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to Jason Smith [:jsmith] from comment #8)
> Can we confirm this is working on 1.4?

Issue does NOT repro on today's Flame 1.4. After tapping on an email address, the screen 'Browse to URL?: mailto:[email address]' appears, and tapping on 'OK', the screen goes directly to Compose email screen without going to a blank screen in between.

Tested on:
Device: Flame
BuildID: 20140602000203
Gaia: ba8d7ef46cadf5d66d189b0b036d0f2e936bece0
Gecko: 384d3410a854
Version: 30.0
Firmware Version: v10g-2
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Comment 10

[Pi Wei Cheng [:piwei] (inactive)]

Bug 1000617 is preventing me to get a deeper window. All builds in between my Last Working and First Broken are broken (can't flash successfully).

Tinderbox Central Regression Window:

Last Working Environmental Variables:
Device: Buri MOZ
BuildID: 20140422193155
Gaia: d8904c5af6152f5d647a93a0c31227171ddecd87
Gecko: ac376a4e8174
Version: 31.0a1
Firmware Version: v1.2-device.cfg

First Broken Environmental Variables:
Device: Buri MOZ
BuildID: 20140425131310
Gaia: 56f79456db5dc3ca010a56d09e1e8cc15a2408db
Gecko: 992ddc6bd0a9
Version: 31.0a1
Firmware Version: v1.2-device.cfg

Last Working Gaia / First Broken Gecko: Issue Does NOT reproduce
Gaia: d8904c5af6152f5d647a93a0c31227171ddecd87
Gecko: 992ddc6bd0a9

Last Working Gecko / First Broken Gaia: Issue DOES reproduce
Gaia: 56f79456db5dc3ca010a56d09e1e8cc15a2408db
Gecko: ac376a4e8174

Gaia Pushlog:
https://github.com/mozilla-b2g/gaia/compare/d8904c5af6152f5d647a93a0c31227171ddecd87...56f79456db5dc3ca010a56d09e1e8cc15a2408db

Comment 11

[Pi Wei Cheng [:piwei] (inactive)]

I just realized that Flame has builds available in this date range and the affected builds seem to be working fine on Flame. I can find a deeper window via Flame if needed.

Comment 12

[Jason Smith [:jsmith]]

(In reply to Pi Wei Cheng from comment #11)
> I just realized that Flame has builds available in this date range and the
> affected builds seem to be working fine on Flame. I can find a deeper window
> via Flame if needed.

Let's try doing that then.

Comment 13

[Pi Wei Cheng [:piwei] (inactive)]

b2g-inbound Regression Window on Flame:

Last Working Environmental Variables:
Device: Flame
BuildID: 20140424023002
Gaia: 4a4a078768423426c7c0fc580c8642bc735033a5
Gecko: 91946180b1e7
Version: 31.0a1
Firmware Version: v10g-2

First Broken Environmental Variables:
Device: Flame
BuildID: 20140424053001
Gaia: 4b6c9d4929c57005ab142e8eb3dc6783d55c427c
Gecko: c30df002e626
Version: 31.0a1
Firmware Version: v10g-2

Last Working Gaia / First Broken Gecko: Issue Does NOT reproduce
Gaia: 4a4a078768423426c7c0fc580c8642bc735033a5
Gecko: c30df002e626

Last Working Gecko / First Broken Gaia: Issue DOES reproduce
Gaia: 4b6c9d4929c57005ab142e8eb3dc6783d55c427c
Gecko: 91946180b1e7

Gaia Pushlog:
https://github.com/mozilla-b2g/gaia/compare/4a4a078768423426c7c0fc580c8642bc735033a5...4b6c9d4929c57005ab142e8eb3dc6783d55c427c

Comment 14

[Jason Smith [:jsmith]]

I think this is broken by bug 916709.

Tim - Can you confirm? If so, can you have someone from your team look into this?

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Fred, could you investigate? Thanks.

Comment 16

[[e-mail]]

I can reproduce this in master. will find out the root cause.

Comment 17

[[e-mail]]

child window factory will receive mailto url and try to open it in popupwindow.
we should filter only http/https to render popupwindow. So the dialog won't shown in this case.


What I got in child window factory:
url:mailto:gasolin@...
name:E-Mail
origin:app://email.gaiamobile.org

Comment 18

[[e-mail]]

Attachment: pull request redirect to github

WIP, need unit test

Comment 19

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Fred, what's the next step of this bug?

Comment 20

[[e-mail]]

I found it's still necessary to show the email composer by pass event to AppWindow.

Still Tracing the right point to fix this issue.

Comment 21

[[e-mail]]

Comment on attachment 8434217 [details] [review]
pull request redirect to github

(it's far from done)
I did some experiment and found if

1. filter the `mailto:` case in AppWindow's contigurations.url,
2. not register SubComponents in popupWindow -> appWindow::render

then the popUpWindow is not shown. but the navigation seems broken.

Any better place to prevent the popupWindow shown?

Comment 22

[(inactive after 6/18) Alive Kuo [:alive]]

I wonder what's the correct behavior of window.open('mailto:....'); for a browser? What's expected on a browser-base OS?
Are we still opening the iframe with any invalid URL in gecko and pass it to gaia via mozbrowseropenwindow?

I guess this issue is not happening before because there was some weird window manager code.

Comment 23

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8434217 [details] [review]
pull request redirect to github

What's the problem to filter in ChildWindowFactory?

Comment 24

[[e-mail]]

If we did the filter in ChildWindowFactory, the email composer is not shown

Comment 25

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Fred Lin [:gasolin] from comment #24)
> If we did the filter in ChildWindowFactory, the email composer is not shown

Please find out why before doing some hacks.
http://mxr.mozilla.org/mozilla-central/source/b2g/components/MailtoProtocolHandler.js#35
Any URL loading which protocol is "mailto" should trigger the mailtoProtocolHandler.
It's strange if we do not render the iframe but still triggers it.

I really suspect why this is not happening before in the old popup manager.

Comment 26

[[e-mail]]

Andrew, what I saw is 

1. email app calling window.open with `mailto:` url, 
https://github.com/mozilla-b2g/gaia/blob/master/apps/email/js/cards/message_reader.js#L639

2. then gecko will emit mozbrowseropenwindow to system app. System app did create the popup window according to the event, but actually it can't handle mailto url.

3. dismiss the blank popupwindow, and composor dialog shows


One issue I found is gecko might not need to emit mozbrowseropenwindow event to gaia if url startswith mailto.


I'm not that familiar with email app and want to figuring how email app trigger the compose dialog, since I did not find a clue to open the compose dialog in message_reader.js ?

Comment 27

[Andrew Sutherland [:asuth] (he/him)]

The short story is that the compose mechanism is always triggered via a web activity (either new/share/view) and the email app only supports disposition: window, so popups will never be right.  The activity is handled/routed in apps/email/js/mail_app.js.


The longer story is that the way this used to work per my investigation around last year when I was looking into the window.open flow as part of an email app security review...
=== excerpt from https://bugzilla.mozilla.org/show_bug.cgi?id=902381#c1 ===
My understanding of how this works is:

- a "mozbrowseropenwindow" event gets fired. https://developer.mozilla.org/en-US/docs/Web/Reference/Events/mozbrowseropenwindow

- the system app's popup manager sees our event and that we asked for "_blank" and converts our request into a 'view' activity. (The window_manager ignores the event because we're not talking about the 'remote' magic flag.)  If we hadn't asked for _blank, PopupManager.open() would trigger and load the URL in an iframe for us.  https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/popup_manager.js#L165
======


In terms of how it seems like the protocol handler is supposed to work (and I guess the browser potentially triggers the email app?) is:

- mailto protocol handler sees mailto, creates data payload of { type: 'mail', URI: uri }.
http://mxr.mozilla.org/mozilla-central/source/b2g/components/MailtoProtocolHandler.js#35

- this gets transformed into a 'new' activity whose payload is the above-created { type: 'mail', URI: uri }
http://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#595

- the email app gets an activity notification which causes us to put a 'compose' card on the UI:
https://github.com/mozilla-b2g/gaia/blob/master/apps/email/js/mail_app.js#L385


Note that, as I mentioned in comment 6, the email app should/will change its behaviour for handling hyperlinks.  I expect we're treating this bug currently as important since it seems like a bug in the window manager that it can end up opening a pop-up that really should end up being automatically closed or never opened in the first place, similar to how Firefox desktop would handle the situation.  I'll spin off the proper bug for the email app now as a see-also.

Comment 28

[(inactive after 6/18) Alive Kuo [:alive]]

Asuth has provided the clues here: that's because in bug 916709's rewrite to popup manager, I miss the part in https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/system/js/popup_manager.js#L165

That means, the feature "window.open('mailto:xxxxx') should open email app" is regressed.

I think what we should do is do the same trick in childWindowFactory to recover it.

Comment 29

[[e-mail]]

Attachment: PR2

Thanks for feedback!

I've come out a PR which successfully trigger the composer view via wrap window.open(url, '_blank') to view activity. (looks like it opened in same email app since only email app shown in task manager)

But after press back button in composer, the email app is closed
https://www.youtube.com/watch?v=5HI1c8Khr3k

Do I miss something from system side?

Comment 30

[[e-mail]]

more clues: 

If I apply above patch and discard the email, no error shows and email is closed to homescreen.


If I change window.open to view activity in email,  then discard the email, error shows:

[JavaScript Error: "TypeError: StackManager.getCurrent(...) is null" {file: "app://system.gaiamobile.org/js/edge_swipe_detector.js" line: 118}]

and then screen is shadowed.

Comment 31

[[e-mail]]

for 'discard the email', I mean 'discard the draft'

Comment 32

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Fred Lin [:gasolin] from comment #31)
> for 'discard the email', I mean 'discard the draft'

Ah, so our compose activities do indicate that they return a value, and once we exit the compose screen (whether via hitting back or synchronous send completing), we will post the result.

When you say "closed to homescreen", do you mean that the email app is still active in the background but the user gets dumped back to the homescreen, or does the email app get closed?

Either way, it's arguable that the email app should remain displayed, but this definitely is an extreme edge-case.

Comment 33

[[e-mail]]

Yes, the email app is still active in the background after press 'discard' button in composer's 'back' dialog.

The transition effect is slide right to the homescreen.

Comment 34

[(inactive after 6/18) Alive Kuo [:alive]]

From the video it looks like:
In email app, (b2g) triggers an activity to call email itself.
So maybe system app thinks the caller of email activity is the email app itself so some weird stuff occurs when activity is done/canceled.

Asuth do we have email app to call window.open('mailto:....') from long time ago?

The solution here might be: check activityCaller's manifest in _handle_mozbrowseractivitydone of AppWindow and if it's the app itself or it's system app, close the caller with normal closing animation and show homescreen app.

Comment 35

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #34)
> Asuth do we have email app to call window.open('mailto:....') from long time
> ago?

I am not 100% clear on what you mean here.  The email app has been using window.open('mailto:...') since v1.0.1-ish.

However, for v2.1 we definitely want to change this on (the see-also) bug 1024856.  We may also be able to address this on v2.0 via uplift.  (Strings will be involved to completely address the problem, which is why complete 2.0 uplift is not possible.)  The email app can be changed for 2.0 (without string changes) if certain changes to the window manager are deemed incorrect/unreasonable.  However, it seems like there is a bug in the window manager, so maybe the email app can be left as-is for 2.0...

> The solution here might be: check activityCaller's manifest in
> _handle_mozbrowseractivitydone of AppWindow and if it's the app itself or
> it's system app, close the caller with normal closing animation and show
> homescreen app.

If it's the same app, maybe it's most appropriate to not close the app at all?  That is what is appropriate/works in the email app case.  So unless we know of another app that causes the same thing, that would make sense.

This seems especially reasonable since it is a returnValue thing, and the email app (as the caller) would get notified that the activity completed (by the email app as the callee), so it can then try and do something reasonable.

Comment 36

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Andrew Sutherland [:asuth] (important r/f/ni reqs only thru Jun 30) from comment #35)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #34)
> > Asuth do we have email app to call window.open('mailto:....') from long time
> > ago?
> 
> I am not 100% clear on what you mean here.  The email app has been using
> window.open('mailto:...') since v1.0.1-ish.

That's the info I need.

> This seems especially reasonable since it is a returnValue thing, and the
> email app (as the caller) would get notified that the activity completed (by
> the email app as the callee), so it can then try and do something reasonable.

Exactly you are not the caller...my previous comment 'assumes' system app mistakenly thinks 'foreground app' is the caller. The caller in this case is system app(b2g) because it's coming from shell.js, so no returnValue will be got by email.

https://github.com/mozilla-b2g/gaia/pull/20477/files#diff-3afdca12898c2a2b5f582bb904d3d0f9R54

Comment 37

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Andrew Sutherland [:asuth] (important r/f/ni reqs only thru Jun 30) from comment #35)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #34)
> > Asuth do we have email app to call window.open('mailto:....') from long time
> > ago?
> 
> I am not 100% clear on what you mean here.  The email app has been using
> window.open('mailto:...') since v1.0.1-ish.
> 
> However, for v2.1 we definitely want to change this on (the see-also) bug
> 1024856.  We may also be able to address this on v2.0 via uplift.  (Strings
> will be involved to completely address the problem, which is why complete
> 2.0 uplift is not possible.)  The email app can be changed for 2.0 (without
> string changes) if certain changes to the window manager are deemed
> incorrect/unreasonable.  However, it seems like there is a bug in the window
> manager, so maybe the email app can be left as-is for 2.0...
> 
> > The solution here might be: check activityCaller's manifest in
> > _handle_mozbrowseractivitydone of AppWindow and if it's the app itself or
> > it's system app, close the caller with normal closing animation and show
> > homescreen app.
> 
> If it's the same app, maybe it's most appropriate to not close the app at
> all?  That is what is appropriate/works in the email app case.  So unless we
> know of another app that causes the same thing, that would make sense.

I guess this is impossible (do we have this for 1.4?).
The email activity will call postError/postResult when user clicks the '<' button and system app will do some transition to move the activity away and show its caller.
The only way to achieve this is hacking email activity to know: if it's just launched 'as an app' and then launched 'as an activity', don't call postError/postResult but close the email writing UI by it own.

Comment 38

[[e-mail]]

looks like there's a general window close issue fired in bug 1024472

Comment 39

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Fred Lin [:gasolin] from comment #38)
> looks like there's a general window close issue fired in bug 1024472

I really don't think window.open related to this issue.

Comment 40

[[e-mail]]

According to web activity doc
https://developer.mozilla.org/en-US/docs/WebAPI/Web_Activities

I think current result after patch is the right behavior because 

1. system call the view activity, which trigger the email composer
2. email composer handle the activity, press back button and discard in dialog will send `activity.postError` to the caller
3. email goes back to the caller (system), activity receive the postResult

Then I found the view activity.onsuccess event is received immediately when view activity is called, which is not the right behavior when email has set activity "returnValue": true in manifest.


@alive can you suggest who should be ni for ?

Comment 41

[[e-mail]]

What I propose the enhancement we could do from system side is:

1. remember the caller app/task while we call view activity in ChildWindowFactory.
2. open the caller app/task after receive activity.onerror or activity.onsuccess

Comment 42

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Fred Lin [:gasolin][OOO 6/23-27] from comment #40)
> Then I found the view activity.onsuccess event is received immediately when
> view activity is called, which is not the right behavior when email has set
> activity "returnValue": true in manifest.
> 

(1) Ask Asuth or (2) trace code in email app to see: why email app do postError/postResult quickly?
BTW, returnValue has nothing to do with how quick onsuccess backs, what's your real problem?

Comment 43

[[e-mail]]

as comment 40 states, I found the view activity.onsuccess event is received immediately when view activity is called in system, which is not the right behavior.

I've added uitest/API/compose email test cases for <a href="mailto:" and `window.open` case. Only window.open case has the weird behavior. So it's window.open dialog or mozActivity API issue.

I'd like to ni guys who can check from mozActivity API side.

Comment 44

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Fred, are you still working on this?

Comment 45

[[e-mail]]

I'm PTO last week and will pick it up.

Comment 46

[[e-mail]]

when we call activity via window.open('_blank'),

in app_window._handle_mozbrowseractivitydone, 
the `callerBottom.instanceID` (this.callerWindow.getBottomMostWindow()) is `homescreen` but not `AppWindow_x`.

Therefore it always return to homescreen after activity is done.


I'd like to know if its possible to overwrite callerWindow in child_window_factory for this case?


(Another case is call mozActivity in email mailto handler, it will return same callee and caller instanceID)

Comment 47

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Fred Lin [:gasolin] from comment #46)
> when we call activity via window.open('_blank'),
> 
> in app_window._handle_mozbrowseractivitydone, 
> the `callerBottom.instanceID` (this.callerWindow.getBottomMostWindow()) is
> `homescreen` but not `AppWindow_x`.
> 
> Therefore it always return to homescreen after activity is done.
> 
> 
> I'd like to know if its possible to overwrite callerWindow in
> child_window_factory for this case?

Why not?

> 
> 
> (Another case is call mozActivity in email mailto handler, it will return
> same callee and caller instanceID)

If the callee is caller we could avoid transition in activitydone handler.

Comment 48

[James Burke [:jrburke]]

Bug 1024856 is now fixed on master and will be uplifted to v2.0. 

With that change, for mailto: links in an email message, they take a short path in the email app to an email compose card. No more window open. For non-mailto: URLs, a 'view' MozActivity is now used.

Comment 49

[[e-mail]]

As Comment 48, this bug does not 2.0+ blocker anymore since it not effect current email app. 

But this bug still exist when app use window.open('dialog') syntax.

Comment 50

[howie [:howie]]

remove blocking flag based on Comment 49

Comment 51

[Jason Smith [:jsmith]]

(In reply to Fred Lin [:gasolin] from comment #49)
> As Comment 48, this bug does not 2.0+ blocker anymore since it not effect
> current email app. 
> 
> But this bug still exist when app use window.open('dialog') syntax.

I don't think so. 3rd party apps could end up triggering the same exact flow, so the fact that the email app is hiding the bug now doesn't lower the priority of this bug at all. Renominating.

Comment 52

[Jason Smith [:jsmith]]

Actually I'm not even going to wait triage on this one. We already know this affects third party apps if window.open workflows can trigger this, so this is still a blocker.

Comment 53

[[e-mail]]

Comment on attachment 8439736 [details] [review]
PR2

Instead of email app, I've add window.open test case in sheets-1~3 app to reproduce the issue.

The popupwindow issue is resolved by patch. The last issue is the activity will go back to homescreen instead of back to the caller window. 

Need your suggestion for proper place to replace the activity's BottomMostWindow.

Comment 54

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8439736 [details] [review]
PR2

Please remove the sheet-app-* change. It's confusing people that we seems to support sheet:// protocol but we never.

Please investigate if this needs improvement.
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/app_window_manager.js#L634

My thought is we could always use AWM.activeApp.getTopMostWindow() as caller.

Comment 55

[[e-mail]]

Comment on attachment 8439736 [details] [review]
PR2

Thanks for advice. 

TBPL passed (Gi bookmark_uninstall_test is always fail in recent builds)
Please kindly review it.

Comment 56

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8439736 [details] [review]
PR2

r+ with nits

Comment 57

[[e-mail]]

Thanks for review!

patch updated and add `callee is caller` test case.

Wait for TBPL test result before merge

Comment 58

[[e-mail]]

merged to gaia-master https://github.com/mozilla-b2g/gaia/commit/184df58f51c8db503961b87d8c326878befe8744

thanks!

Comment 59

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/d65d33976cd7e17e622135514f7e06a76bb5e9e7

Comment 60

[Alissa（leave from Mozilla）]

Attachment: flame2.1 .3gp

This issue has been successfully verified on Flame 2.1, 2.0
See attachment:flame2.1.3gp
Reproducing rate: 0/5
FLame 2.0 new build:
Gaia-Rev        f9d6e3d83c3922e9399a6c27f5ce4cdd27bdfd05
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/45112935086f
Build-ID        20141126000203
Version         32.0

Flame 2.1 new build:
Gaia-Rev        db2e84860f5a7cc334464618c6ea9e92ff82e9dd
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/211eae88f119
Build-ID        20141126001202
Version         34.0