Extension's preferences window behaves inconsistently in Firefox 3.5.6

zmichl

unread,

Jan 20, 2010, 11:32:28 AM1/20/10

to

Hi, my extension has a simple preferences window with checkbox as
follows:
<prefwindow ...>
<preferences>
<preference id="flag" name="extensions.name.flag" type="bool"/
>
</preferences>
<checkbox preference="flag" label="flag"/>
</prefwindow>

1. When I set "browser.preferences.instantApply" to true, then open
pref window and click checkbox, "extensions.name.flag" changes its
value immediately. -> It behaves correctly.
When I change "browser.preferences.instantApply" to false and then
click checkbox again (pref windows is still open and has not been
reopened), "extensions.name.flag" changes its value immediately again.
-> I guess this behaves correctly again (ok, I changed instantApply,
but window probably should has the same behaviour until is reopened).

But opposite case:

2. When I set "browser.preferences.instantApply" to false, then open
pref window and click checkbox, "extensions.name.flag" does not change
its value immediately. -> It behaves correctly.
When I change "browser.preferences.instantApply" to true and then
click checkbox again (pref windows is still open and has not been
reopened), "extensions.name.flag" changes its value immediately. -> I
guess it should not do it until ondialogaccept is called (window
should has the same behaviour until is reopened).

So I do not know which of these cases (1. or 2.) is correct, but there
is evidently inconsistency between them. Is it a bug or doing I am
something wrong?

Thanks,
Zbynek

zmichl

unread,

Jan 20, 2010, 12:01:10 PM1/20/10

to

On 20 led, 17:32, zmichl <zbynek.mi...@nic.cz> wrote:
> So I do not know which of these cases (1. or 2.) is correct, but there
> is evidently inconsistency between them. Is it a bug or doing I am
> something wrong?

So it is probably bug of Firefox 3.5, because I tried to test also
Firefox 3.0 and it has not this issue.

Mike Connor

unread,

Jan 20, 2010, 12:35:51 PM1/20/10

to zmichl, dev-apps...@lists.mozilla.org

The short answer is "who cares?" At best, the real-time implications
of changing a pref that impacts how a binding behaves are
unspecified. I'm surprised the binding does anything differently, but
I don't know if it matters, since this pref isn't exposed and isn't
going to be toggled...

-- Mike

> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox

Mike Connor

unread,

Jan 20, 2010, 1:02:54 PM1/20/10

to zmichl, dev-apps...@lists.mozilla.org

Sorry, that was far too flippant. What I should have asked was "is
this a real-world problem you need to solve, or is it simply undefined
behaviour which seems unintuitive?

-- Mike

On 20-Jan-10, at 12:35 PM, Mike Connor wrote:

> The short answer is "who cares?" At best, the real-time
> implications of changing a pref that impacts how a binding behaves
> are unspecified. I'm surprised the binding does anything
> differently, but I don't know if it matters, since this pref isn't
> exposed and isn't going to be toggled...
>
> -- Mike
>
> On 20-Jan-10, at 11:32 AM, zmichl wrote:
>

zmichl

unread,

Jan 21, 2010, 8:21:20 AM1/21/10

to

On 20 led, 19:02, Mike Connor <mcon...@mozilla.com> wrote:
> Sorry, that was far too flippant. What I should have asked was "is
> this a real-world problem you need to solve, or is it simply undefined
> behaviour which seems unintuitive?

Example: You have opened extension's pref window, instantApply is
false, thus window contains OK and Cancel buttons. Then you change
instantApply to true (while pref window is still opened). Now
preferences in that window immediately change its behaviour according
to instantApply change, but they shouln't, because window still has OK
and Cancel buttons, so the same behaviour should be preserved until
pref window is reopened.

As I said in my last comment, in Firefox 3.0 it works fine, but
Firefox 3.5 has a problem with it and user could be confused with this
behaviour.

Zbynek

Mike Shaver

unread,

Jan 21, 2010, 8:29:17 AM1/21/10

to zmichl, dev-apps...@lists.mozilla.org

I agree that that sounds like a bug, worth filing. It would be very
useful to know more about when it regressed; if you have a test case,
binary-searching on betas and nightlies would really help get to the
bottom of it. To be honest, I'm surprised that FF3 got it right, but
I don't doubt that you're reporting it correctly!

Mike

zmichl

unread,

Jan 21, 2010, 10:51:57 AM1/21/10

to

On 21 led, 14:29, Mike Shaver <mike.sha...@gmail.com> wrote:

I found out that 3.0.17 is ok and 3.5b4pre no longer so regression
must be between them.

Zbynek

Mike Connor

unread,

Jan 21, 2010, 12:44:48 PM1/21/10

to zmichl, dev-apps...@lists.mozilla.org

First guess is https://bugzilla.mozilla.org/show_bug.cgi?id=451025,
since this is what mucked with how the instantApply property. Please
go ahead and file a bug on this, and cc me?

-- Mike

Justin Dolske

unread,

Jan 24, 2010, 2:38:07 AM1/24/10

to

On 1/21/10 5:21 AM, zmichl wrote:
>> What I should have asked was "is
>> this a real-world problem you need to solve, or is it simply undefined
>> behaviour which seems unintuitive?
>

> Example:[...]

I'm still left wondering what the actual problem is. In other words, why
are you flipping the instantApply pref like that? AIUI, the pref is used
to make pref windows match platform conventions (or, if nothing else, to
make the app work the way the developer wants). Changing how it works at
run time sounds like overly confusing and complicated UI.

Justin

zmichl

unread,

Jan 25, 2010, 5:03:34 AM1/25/10

to

On 24 led, 08:38, Justin Dolske <dol...@mozilla.com> wrote:
> I'm still left wondering what the actual problem is. In other words, why
> are you flipping the instantApply pref like that? AIUI, the pref is used
> to make pref windows match platform conventions (or, if nothing else, to
> make the app work the way the developer wants). Changing how it works at
> run time sounds like overly confusing and complicated UI.

I am not intended to change instantApply at run time.

But imagine this situation:
User will open pref window of my extension, then open
"about:config" (while my pref window is still opened) and change
instantApply for any reason. From now my pref window behaves
incorrectly in Firefox >3.5. So I would like to handle this situation.

Zbynek

zmichl

unread,

Jan 25, 2010, 9:13:25 AM1/25/10

to

On 21 led, 18:44, Mike Connor <mcon...@mozilla.com> wrote:
> First guess ishttps://bugzilla.mozilla.org/show_bug.cgi?id=451025,

> since this is what mucked with how the instantApply property. Please
> go ahead and file a bug on this, and cc me?

I have reported it as a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=541959

Zbynek

Shawn Wilsher

unread,

Jan 25, 2010, 10:31:55 AM1/25/10

to dev-apps...@lists.mozilla.org

On 1/25/2010 2:03 AM, zmichl wrote:
> "about:config" (while my pref window is still opened) and change
> instantApply for any reason. From now my pref window behaves
> incorrectly in Firefox>3.5. So I would like to handle this situation.
>

It is highly unlikely that a user would do this.

Cheers,

Shawn

Mike Connor

unread,

Jan 25, 2010, 9:27:11 PM1/25/10

to Shawn Wilsher, dev-apps...@lists.mozilla.org

On 25-Jan-10, at 10:31 AM, Shawn Wilsher wrote:

> On 1/25/2010 2:03 AM, zmichl wrote:

>> "about:config" (while my pref window is still opened) and change
>> instantApply for any reason. From now my pref window behaves
>> incorrectly in Firefox>3.5. So I would like to handle this situation.
>>

> It is highly unlikely that a user would do this.

This is true.

That said, when we go from deterministic to non-deterministic, we
probably did something wrong there, and it's worth fixing.

-- Mike