Closed Bug 609281 Opened 9 years ago Closed 8 years ago

Sharing a link using facebook does not hide the awesomescreen

Categories

(Firefox for Android Graveyard :: General, defect)

Other
Other
defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: anamaria.moldovan, Assigned: mbrubeck)

Details

Attachments

(2 files)

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.
Attached image The actual results
Assignee: nobody → mbrubeck
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 609184
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
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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.)
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → INVALID
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.
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)
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.
Status: RESOLVED → REOPENED
tracking-fennec: --- → ?
Resolution: INVALID → ---
tracking-fennec: ? → 2.0+
Summary: Sharing a link using facebook fails. → Sharing a link using facebook does not hide the awesomescreen
Attached patch patchSplinter Review
Attachment #494511 - Flags: review?(mark.finkle)
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.
Attachment #494511 - Flags: review?(mark.finkle) → review+
Whiteboard: [fennec-checkin-postb3]
(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...
(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.
pushed:
http://hg.mozilla.org/mobile-browser/rev/b3c2232b6583
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Whiteboard: [fennec-checkin-postb3]
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)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [fennec-checkin-postb3]
Whiteboard: [fennec-checkin-postb3]
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.
tracking-fennec: 2.0+ → ---
This is fixed now, maybe by bug 621506.
Status: REOPENED → RESOLVED
Closed: 9 years ago8 years ago
Resolution: --- → FIXED
Samsung Galaxy SII (Android v2.3.3)
Mozilla/5.0 (Android; Linux armv7l; rv:9.0a1) Gecko/20110909 Firefox/9.0a1 Fennec/9.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.