608701 - Doesn't warn unexpected flag change

Status: NEW

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

When I posted something to bugs, I overwrote some blocking flags of bugzilla.mozilla.org's bug unexpectedly if another user change the flag. At that time, I don't see the warning page.

I'm not sure the change was done between loading the page and posting something. E.g., the page may have been restored by session restore of Fx. And Fx might have loaded the page but it had set the state of controls to non-latest values.

I think that even if the cause is the latter one, when I'll change the flag *from* a state which I cannot set it to, I want to see a warning page because I cannot restore the flag by myself.

Comment 1

[Frédéric Buclin]

Flag changes trigger the midair collisions page, so you probably refreshed your page. I don't want to see an intermediate page when you override flags. If you refresh your page, there is no reason to suspect an unwanted change. And all fields could be unintentionnally modified by the user. We certainly don't want a confirmation page for everything. Personlly, this is WONTFIX, even when overriding flags you cannot grant nor deny.

Comment 2

[Max Kanat-Alexander]

So, the bug reported is, "I don't get a midair if I refresh my page"? That wouldn't be a bug.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #1)
> Flag changes trigger the midair collisions page, so you probably refreshed your
> page.

Hmm.

> I don't want to see an intermediate page when you override flags. If you
> refresh your page, there is no reason to suspect an unwanted change.

I did NOT refresh the page myself. So, I guess that the page is restored from crash or applying update automatically. If your above sentence is correct, Gecko uses latest values only for input[type=hidden] and restores latest values for other controls. It sounds bad.

Ccing Boris. Boris, is the above paragraph correct? And is that intentional behavior? If you're not a peer of the form control, sorry for the spam.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I have no idea what session restore does or doesn't do; iirc it does its own saving/restoration.

Normal DOM form control state restoration only saves/restores controls whose values were changed from the default value.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you, Boris. I confirmed that when I restart Fx, Fx loads latest page but restores the form control states to last value. I think that this is a bug of Fx, but I'm not sure whether WONTFIX is good choice for bugzilla because such unexpected behavior isn't good thing for web applications. I think that, ideally, if it's possible to prevent such miss post, web applications should do something.

Comment 7

[JK]

Seriously, we need this fixed ASAP, before people get banned or have their field editing rights removed for abusing the fields. Otherwise, admins should be informed about the existence of this bug, so that they do not ban people due to this bug.

(Bug 619057 comment #9)
> (Do that again, jmjeffery, and I'll change your bz privs so that you can't.
> Midair collision warnings mean something, and please take the time to observe
> them)

The refresh button does not update the fields, and there are no midair collison warnings, if the refresh button is used.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> The refresh button does not update the fields,

A force-refresh does, fwiw...