Yeah, on line 73 it is set to false:
*boolean* useBrowserHistory = *false*;
but when we init it at line 643:
*if* ("true".equals(*this*.getProperty("useBrowserHistory", "true")))
{
it gets set to true if the property hasn't been set. So that line should
change to:
*if* ("true".equals(*this*.getProperty("useBrowserHistory", "false")))
{
Simon Mac Donald
http://hi.im/simonmacdonald
On Fri, Jun 29, 2012 at 2:42 PM, Joe Bowser <bows...@gmail.com> wrote:
> It was the default in my repo. I think we're doing something that's
> causing the history to be added twice with native history. We should
> have that default to false for now.
>
> Joe
>
> On Fri, Jun 29, 2012 at 11:38 AM, Simon MacDonald
> <simon.macdon...@gmail.com> wrote:
> > Yeah, if userBrowserHistory is set to false everything works like it
> > should. Perhaps we should make this the default for 1.9?
> >
> > Simon Mac Donald
> > http://hi.im/simonmacdonald
> >
> >
> > On Fri, Jun 29, 2012 at 2:20 PM, Joe Bowser <bows...@gmail.com> wrote:
> >
> >> OK, if I use the browser history, I get this bug. I'm working on it
> >> now, but if you set useBrowserHistory to false, it should work like it
> >> did in 1.8.
> >>
> >> Joe
> >>
> >> On Fri, Jun 29, 2012 at 10:37 AM, Joe Bowser <bows...@gmail.com> wrote:
> >> > This sounds like a history bug. Are you using browser history or our
> >> history?
> >> >
> >> > On Fri, Jun 29, 2012 at 10:29 AM, Filip Maj <f...@adobe.com> wrote:
> >> >> Hey Simon,
> >> >>
> >> >> I just pulled the latest Android + JS and don't see that behavior on
> my
> >> >> Galaxy Nexus running 4.0.4 nor my Nexus S running 2.3.6.
> >> >>
> >> >> Are you sure?
> >> >>
> >> >> On 6/29/12 10:23 AM, "Drew Walters" <deedu...@gmail.com> wrote:
> >> >>
> >> >>>Is this in anyway related to this change:
> >> >>>
> >> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=commi
> >> >>>t;h=95feb23c6f2bcd8303ffb44cea41cc7a2e7adee7
> >> >>>
> >> >>>Reason I ask is I have a test case that allows me to assign multiple
> >> >>>handlers to button overriding listeners. Prior to the above change
> the
> >> >>>behavior was:
> >> >>>
> >> >>>1. Add handler1 event listener for menu button
> >> >>>2. Press menu button
> >> >>>3. handler1 called
> >> >>>4. Add handler2 event listener for menu button
> >> >>>5. Press menu button
> >> >>>6. handler1 called, handler2 called.
> >> >>>
> >> >>>Now the behavior is (Note change in #5):
> >> >>>
> >> >>>1. Add handler1 event listener for menu button
> >> >>>2. Press menu button
> >> >>>3. handler1 called
> >> >>>4. Add handler2 event listener for menu button
> >> >>>5. handler2 called
> >> >>>6. Press menu button
> >> >>>7. handler1 called, handler2 called.
> >> >>>
> >> >>>I'm not sure a developer would want their newly assigned event
> >> >>>handler to be immediately called when the event may have occurred a
> >> >>>long time in the past. Is this really the desired behavior?
> >> >>>
> >> >>>On Fri, Jun 29, 2012 at 12:20 PM, Filip Maj <f...@adobe.com> wrote:
> >> >>>> Btw docs are ready to tag
> >> >>>>
> >> >>>> On 6/29/12 10:09 AM, "Simon MacDonald" <simon.macdon...@gmail.com>
> >> >>>>wrote:
> >> >>>>
> >> >>>>>So anyway, I grabbed the latest js and but it into the Android
> project
> >> >>>>>and
> >> >>>>>began to run mobile spec tests. It seems like the back button is
> >> >>>>>incredibly
> >> >>>>>borked again.
> >> >>>>>
> >> >>>>>Here is what I see:
> >> >>>>>
> >> >>>>>1) Start mobile spec
> >> >>>>>2) Click 'Accelerometer' button
> >> >>>>>3) Shows the 'Accelerometer' page
> >> >>>>>4) Click hw back button
> >> >>>>>5) Shows the main mobile spec page
> >> >>>>>6) Click 'Audio' button
> >> >>>>>7) Click the hw back button
> >> >>>>>8) Shows the main mobile spec page
> >> >>>>>9) Click the hw back button
> >> >>>>>10) Shows the 'Accelerometer' page
> >> >>>>>11) Shows the main mobile spec page
> >> >>>>>12) Click the hw back button
> >> >>>>>13) Shows the main mobile spec page
> >> >>>>>14) Click the hw back button
> >> >>>>>15) Finally exits the app
> >> >>>>>
> >> >>>>>So yeah, that should get fixed before we release 1.9.0 or expect a
> lot
> >> >>>>>of
> >> >>>>>belly-aching from the users. I've got grab some lunch but will
> look at
> >> >>>>>it
> >> >>>>>this afternoon.
> >> >>>>>
> >> >>>>>Simon Mac Donald
> >> >>>>>http://hi.im/simonmacdonald
> >> >>>>>
> >> >>>>>
> >> >>>>>On Fri, Jun 29, 2012 at 12:34 PM, Filip Maj <f...@adobe.com> wrote:
> >> >>>>>
> >> >>>>>> don¹t tag docs just yet. I'm gonna get those issues resolved in
> the
> >> >>>>>>next
> >> >>>>>> hour
> >> >>>>>>
> >> >>>>>> On 6/29/12 9:29 AM, "Michael Brooks" <mich...@michaelbrooks.ca>
> >> wrote:
> >> >>>>>>
> >> >>>>>> >For Docs, the only outstanding issue is CB-967 [1] (Cordova
> >> WebView).
> >> >>>>>> >However, it can be pushed 2.0.0 and added to 1.9.0 docs when
> >> >>>>>>written. I
> >> >>>>>> >say
> >> >>>>>> >tag and release.
> >> >>>>>> >
> >> >>>>>> >Hopper is a great word choice for 9am. mmm... fresh coffee.
> >> >>>>>> >
> >> >>>>>> >https://issues.apache.org/jira/browse/CB-967
> >> >>>>>> >
> >> >>>>>> >On Fri, Jun 29, 2012 at 9:25 AM, Simon MacDonald
> >> >>>>>> ><simon.macdon...@gmail.com>wrote:
> >> >>>>>> >
> >> >>>>>> >> I got nothing else in the hopper for 1.9.0 right now. Let's
> start
> >> >>>>>> >>tagging.
> >> >>>>>> >>
> >> >>>>>> >> Simon Mac Donald
> >> >>>>>> >> http://hi.im/simonmacdonald
> >> >>>>>> >>
> >> >>>>>> >>
> >> >>>>>> >> On Fri, Jun 29, 2012 at 12:25 PM, Filip Maj <f...@adobe.com>
> >> wrote:
> >> >>>>>> >>
> >> >>>>>> >> > We gonna do this?
> >> >>>>>> >> >
> >> >>>>>> >> >
> >> >>>>>> >>
> >> >>>>>>
> >> >>>>>>
> >> >>>>
> >> >>
> >>
>
