Found this during bug 911053. STR: 1. Open browser -> Save bookmark 2. Go to homescreen 3. Open UITest -> Save bookmark The content of second activity is empty, but when we go back to the first activity, the arguments passed in second time is showed in first activity. That means the system message is sent to the first manifestURL+pageURL matched frame. I think it's because http://mxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessageManager.js#204 http://mxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessageInternal.js#553 http://mxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessageInternal.js#160 http://mxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessageInternal.js#258 http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#772 By the design to this flow, it seems we just cannot have two pages opened for the same type of message but different message content. My thought: If we know the first page is already dealing with some message, could we just pend the message again until a fresh new page is opened?

(In reply to Alive Kuo [:alive][11/4-11/8 at SFO ww.] from comment #0) > Found this during bug 911053. > > STR: > 1. Open browser -> Save bookmark > 2. Go to homescreen > 3. Open UITest -> Save bookmark > > The content of second activity is empty, > but when we go back to the first activity, the arguments passed in second > time is showed in first activity. > That means the system message is sent to the first manifestURL+pageURL > matched frame. Yes, we checked that, which means different frames can set their own system message handlers respectively as long as their (manifestURL+pageURL) are different. I don't understand why we would encounter this issue if the frames/pages are actually different ones? Btw, we just solved an issue at bug 930296 by backing out bug 927363. Not sure if they are related. :P

We may have two frame with same manifest + same pageURL in the future.

This also triggers bug 946678: an inline activity that has no href (or a href that is identical to the launch_path).

Hi Sean, this is the bug that we discussed about with Alive.

A proposal to fix this: * SystemMessage in gecko may need not to keep the instance list, at least, do not maintain the table by its url. * Let gaia system app decides which mozbrowser iframe to send the system message. * For inline activities, system app will create the mozbrowser iframe and ask gecko to trigger system message handler for the newly created iframe each time an activity is triggered. * For window activities, system app will look for the existing app. If it's already opened, tell gecko to send to. Otherwise create it and do the same thing. * For normal system messages, do broadcasting for gecko.

Hi Luke and John, is this bug what you're talking about?

Gene, Comment 2 is exactly we are talking about. Alive's proposal can fix it. But we may need to think about the nested OOP case. If an app or widget is opened at nested iframe whom system app doesn't aware, how should we deal with the system message?

Hi Howie, The issue also been reported by partner as bug 1114912. Please consider this as higher priority maybe version after 2.2? Thanks!

Alive, it would looks like the present bug would fix what I was trying to fix in bug 1103560. Can your confirm ? If so, then I'll mark bug 1103560 as a dupe.

(In reply to Alexandre LISSY :gerard-majax from comment #10) > Alive, it would looks like the present bug would fix what I was trying to > fix in bug 1103560. Can your confirm ? If so, then I'll mark bug 1103560 as > a dupe. Definitely not a dupe. This bug is more likely for all apps because system app could create any number of app instances but will run into this problem so we just cannot have multiple instances from one app; but system app itself is not able to have two instances. What you suggested in bug 1103560 makes sense - any app including system app should have only one system message handler for any one system message (1 to 1 mapping) but it is out of scope of this bug.