609281 - Sharing a link using facebook does not hide the awesomescreen

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Anna (Waverley)]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101028 Firefox/4.0b8pre
Build Identifier: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b8pre)Gecko/20101103 Firefox/4.0b8pre Fennec /4.0b3pre

When trying to share a link from "All Pages" view the browser attempts to open that site, even though the native application is presently installed.



Reproducible: Always

Steps to Reproduce:
1. Make sure you have some history.
2. From awesomescreen, context-click tap the URL from "All Pages" view, and click on "Share link"
3. The list of supported Native Apps for device appears.
4. Choose facebook.


    
Actual Results:  
The browser attempts to open the site even though the native application (facebook) is installed on the device.

Expected Results:  
The page should be posted on the facebook profile.

I. When trying to share the link with gmail everything works fine. 

II. Also, when:

      1. visit a url (eg. http://www.mozilla.org)
      2. Click on the site identifier icon
      3. Click on "Share Page" option

 The page (www.mozilla.org) is posted on the facebook profile.

Comment 1

[Anna (Waverley)]

Attachment: The actual results

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

Not a dupe. This bug is about using the "Share Page" inside Fennec. Bug 609184 is about using the "Share" button on the webage at touch.facebook.com

Comment 4

[Matt Brubeck (:mbrubeck)]

This is expected behavior.  The native Facebook app for Android opens a web page in the default browser when you use its "share page" command.  (This isn't related to Fennec - the same thing is true if you use the "Share page" command in the stock Android browser.)

Comment 5

[Anna (Waverley)]

When context-click tapping on a link from "All Pages" view a dialog with the option "Share link" appears (like the testcase indicates). Tapping the "Share link" option makes available a list of supported Native Apps. I choose Facebook. 
If I choose "Complete this application using Browser" the link is posted on the Facebook profile.
If I choose "Complete this application using Fennec" the behavior is the one seen in the attached photo. Only after pressing the system back button the Facebook profile appears and the link is posted on the profile.

Comment 6

[Anna (Waverley)]

1. Set Fennec as default browser
2. Open AwesomeBar->All Pages
3. Long tap on an available item . Context menu is displayed with one option: Share page
4. Choose to share it with Facebook

Expected results: One is taken to "Post To Profile" page (if not logged in, is asked to enter username and password first ).  

Actual results: Awesome bar->All pages remains displayed, while the URL bar contains the correct information (link and favicon to Facebook) 

see screenshot above


Note: Test case in Litmus is: https://litmus.mozilla.org/show_test.cgi?id=12770 (Step 4 from Steps to perform)

Comment 7

[Matt Brubeck (:mbrubeck)]

Okay, it looks like the problem is that we don't automatically dismiss the awesomescreen when the command-line handler opens a link in a new tab.  Looks like the same is true if you open a link from another app while the awesomescreen or tool panel is open.

Comment 8

[Matt Brubeck (:mbrubeck)]

Attachment: patch

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 494511 [details] [diff] [review]
patch

Just for completeness, could you add the same call to the openURI method as well?

I wonder if we shouldn't try to fix this in a more centralized manner. Maybe closing autocomplete at the same time we fire the URLChanged event.

Comment 10

[Matt Brubeck (:mbrubeck)]

(In reply to comment #9)
> Just for completeness, could you add the same call to the openURI method as
> well?

Not sure what you mean - I added the call to _getBrowser, which is called by both openURI and openURIInFrame.

> I wonder if we shouldn't try to fix this in a more centralized manner. Maybe
> closing autocomplete at the same time we fire the URLChanged event.

I thought of this, but didn't do it because I think there are cases where we don't want it - for example, when you use "open link in new tab" from the awesomescreen context menu.

Perhaps we could do it in Browser.addTab only when aBringFront is true...

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #10)
> (In reply to comment #9)
> > Just for completeness, could you add the same call to the openURI method as
> > well?
> 
> Not sure what you mean - I added the call to _getBrowser, which is called by
> both openURI and openURIInFrame.

Darn. Wasn't enough context in the patch and I was too lazy to go look at the code. You've got it covered. Sorry.

> > I wonder if we shouldn't try to fix this in a more centralized manner. Maybe
> > closing autocomplete at the same time we fire the URLChanged event.
> 
> I thought of this, but didn't do it because I think there are cases where we
> don't want it - for example, when you use "open link in new tab" from the
> awesomescreen context menu.
> 
> Perhaps we could do it in Browser.addTab only when aBringFront is true...

I'm worried about the cases where we don't want it too. Let's wait and see if it becomes more of a problem.

This patch is ready to go as-is.

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

pushed:
http://hg.mozilla.org/mobile-browser/rev/b3c2232b6583

Comment 13

[Anna (Waverley)]

I can still reproduce it on: Nokia N900 (Build ID: Mozilla /5.0 (Maemo;Linux armv7l;rv:2.0b8pre) Gecko/20101210 Firefox/4.0b8pre Fennec/4.0b3pre)

Comment 14

[Matt Brubeck (:mbrubeck)]

This takes a different code path on Maemo 5, where it uses the built-in sharing feature (rather than native apps as on Android or MeeGo).  Removing blocking-fennec; please re-nominate if we are blocking on Maemo-specific UI polish.

Comment 15

[Matt Brubeck (:mbrubeck)]

This is fixed now, maybe by bug 621506.

Comment 16

[Aaron Train [:aaronmt]]

Samsung Galaxy SII (Android v2.3.3)
Mozilla/5.0 (Android; Linux armv7l; rv:9.0a1) Gecko/20110909 Firefox/9.0a1 Fennec/9.0a1