Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-1595] openPhotoGallery / showCamera callbacks fail when showing modal window on Android

GitHub Issuen/a
Resolution Date2012-08-15T14:43:33.000+0000
Affected Version/sn/a
Fix Version/sRelease 3.0.0
Labelsmodule_window, qe-review, qe-testadded
ReporterBrion Vibber
AssigneeNeeraj Gupta


When calling Titanium.Media.openPhotoGallery or .showCamera from a modal windows on Android, the camera/gallery dialogs show and operate but my success, cancel, and error callbacks never get called so my application can't process the image. This is a problem for our StatusNet Mobile social networking client, which needs to be able to take or select photos from a modal message-compose dialog.

var window = Titanium.UI.createWindow({
    title: "Photo test",
    backgroundColor: 'black'
var button = Titanium.UI.createButton({
    left: 20,
    right: 20,
    top: 120,
    height: 32,
    title: "Push me"

button.addEventListener('click', function() {
    var popoverView;
    var arrowDirection;
        success:function(event) {

    modal: true

Removing the 'modal: true' makes it work just fine, and I see output in the debug log when my callbacks fire.

Testing current git builds of mobile, on Android 2.2 + APIs.


  1. Brion Vibber 2011-04-15

    Turns out this is affecting all heavyweight windows, not just modals -- so that includes those with fullscreen or navBarHidden set as well.

    This is a release blocker for StatusNet Mobile, since we've gotten back-button navigation working in Android by using heavyweight windows for each level, and have also removed the system title bar by putting navBarHidden on all the windows which also turns them into heavyweight windows.

    Assigning to our support contact; we'll also file a helpdesk request referencing this bug.

  2. Brion Vibber 2011-04-15

    Suggested workaround from support was to call from inside the heavyweight window's context (so giving it a url with its own little .js file) and pass the data back to the main context through application-wide events.

    This seems to do the job for now, though we had issues with writing the blobs to temporary files (fixed in f2eca06d -- thanks to Marshall for that fix!)

  3. Bill Dawson 2011-04-15

    The callbacks actually do get called, but not until you back out of that heavyweight window. (which for all intents and purposes is as annoying as them not getting called at all. :) )

    Since the workaround (giving your heavyweight window its own .js and putting event logic for its controls in there -- which is something I always do and recommend) is working okay for you, I'm bumping this down to 'medium.' We have a re-engineering of our contexts already under way for a future release, so we'll have to see how this use case fits in when we have that ready to test.

  4. Brion Vibber 2011-04-15

    Great, thanks for looking into it!

  5. Dawson Toth 2011-04-26

    A client has reported this fixed in 1.6.2. Just tested with 1.6.2, and the original sample code works for me as well. So... pass on both accounts.
  6. Shannon Hicks 2011-10-20

    Just ran into this bug in 1.7.3
  7. Florian Schnell 2011-10-31

    I have had this issue with 1.7.3, too. Our application is based on one window to which we add and remove views. There is one button calling the camera attached directly to the window and another one to one of the subviews. Clicking on the first one works fine, the second launches the camera but then no success callback is invoked. Workaround for me was to change the click-callback for the second button. Instead of calling the showCamera it is now fireing a click event on the first button - which is attached to the heavy window. Thought this might be helpful, also wanted to share this good feeling after hours of bug tracking!
  8. David Rodriguez 2011-11-29

    I'm having this problem with 1.7.5 too. The callbacks aren't called when using navBarHidden:true. Any workarounds from a single context or do I have to launch another window context without navBarHidden for this to work? Thanks.
  9. connysvensson 2011-12-23

    I'm experiencing the same problem in both 1.7.5 and 1.8.0 (haven't tested in
  10. Keith Gable 2012-01-06

    We are experiencing this issue in two different apps. Changing to a lightweight window does not resolve it in one app (but does in the other). I'm going to try to switch BACK to heavyweight and add an event listener for a synthetic event on the window and then fire that synthetic event when I need to capture a photo, and see what happens. Also, in this exact app, there is a heavyweight window that functions as expected.
  11. Keith Gable 2012-01-06

    Firing a synthetic event on the window (appname:capturephoto and appname:choosephoto) and adding event listeners for those events on the window worked in my case.
  12. Dan Tamas 2012-01-09

    @Keith - can you elaborate a little how you overcame the issue? When do you trigger the synthetic events? Thank you.
  13. Keith Gable 2012-01-10

    I add an event listener to win listening for my synthetic/fake events, which then opens the camera or gallery. I fire the event on win whenever I want to show the camera or gallery.
  14. Dan Tamas 2012-01-10

    @Keith - so opening the gallery through a synthetic event will trigger the success event when the photo is selected?
  15. Keith Gable 2012-01-10

    Yes, but only if your success function is created within the synthetic event's handler function.
        win.addEventListener("blah:camera", function () {
            success: function (e) {
              // whatever
    It also works on iOS this way.
  16. Dan Tamas 2012-01-10

    Thnx, I'll try and let you know
  17. Junaid Younus 2012-08-15

    Tested on a Samsung Galaxy S2 using TiSDK 2.2.0v20120814103312, unable to reproduce the issue, working fine for me. Ticket closed.
  18. Shyam Bhadauria 2012-09-10

    Environment used for verification - Titanium SDK: 2.2.0.v20120907162025 Titanium  Studio: Device - LG-P970 Android 2.2.2 Machine OS - MAC 10.8

JSON Source