360559 - approval data of an extension applied to another one due to history

Status: RESOLVED WONTFIX

(addons.mozilla.org Graveyard :: Admin/Editor Tools, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1) Gecko/20061010 Firefox/2.0

Going back several steps in the history, the approval data of an extension is applied to another one without warning the reviewer. So there are unwanted approving / denyings.

Reproducible: Didn't try

Comment 1

[Mike Shaver (:shaver emeritus)]

I don't understand what you mean here, sorry.  What do you mean by "going back several steps in the history"?  Can you give more specific information about what you did, and what you saw?

Comment 2

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

1. I approved some add-ons and denied one because of a maxVersion 10.0 for Flock ( https://addons.mozilla.org/firefox/838 ), querying the queue for each one extra. Later, I had a chat with a developer on IRC and jumped backed to the approval queue by selecting the page from the history button (it wasn't the last approval queue page in history, because reloading the last one would have submitted the last approval again. Going back in history loads the AQ again, I filled in the data for approving the add-on about I had talked to the developer. After pressing the submit button, this add-on had been approved and another one ( https://addons.mozilla.org/firefox/3794 ) was denied by me (what I didn't wanted) with the text from the first denial. The problem may be a Firefox problem (filling in old data even if site structure has changed), but there should be a (java)script which cleanes all inputs / textareas or add-on-related input / textarea names.

Comment 3

[Mike Shaver (:shaver emeritus)]

Ah, OK, thank you.  I thought you were talking about the item's history; my mistake!

I wonder if this is indeed a Firefox bug, since we'll be loading the page from the network where the content will be different and the form names will be the same; cc-ing bz here optimistically in case he can point us in the right direction, or tell us what other specific data we should be gathering to diagnose better.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Er... I'm not sure I follow the steps to reproduce, mostly because I'm not at all familiar with the workflow in question.  Is the point that you loaded a page from session history that had a form that you had submitted, edited the entries in said form, and submitted again and that it behaved weirdly?

Comment 5

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

"Is the point that you loaded a page from session history that had a form that you had submitted"
Yes, now I filled/changed other fields and the old data which belonged to an extension which wasn't anymore in queue (because of the first submission) were put in the fields of another extension (maybe the same place on the page) and because they are hidden in the approval queue, I didn't saw this and had the accident of denying an extension that I didn't wanted.

(Why I used the history and not the menu? The history is aside of the reload button which I someone like to force to reload the page every xx minutes. The last page couldn't be used because reloading would mean sending post data again.)

Comment 6

[Boris Zbarsky [:bzbarsky]]

Oh.  So some hidden form fields got filled out differently from the first time, because the server end of things had changed?  But the visible fields got reloaded with the text you'd typed in, so you thought that the whole page was in the exact state it was in when you left it?

I seem to recall we don't restore the state for hidden inputs...

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

They aren't hidden inputs, but the approval queue hides the forms using DHTML/Javascript and I won't expand/show all forms (for each one click).

Comment 8

[Justin Scott [:fligtar]]

They're hidden inputs. As I recall, the AQ uses an incremental ID system for the fields, like testedos_34, testedapps_34 and also has hidden fields like id_34. The id of the add-on is stored in the hidden text field which is apparently not the same as it was when going back in history. So, the visible inputs stay the same from the old incremental id and the id of the extension (hidden) changes.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Yeah, that would be a known issue, then...

Comment 10

[Mike Shaver (:shaver emeritus)]

I summon the gavinbot to find a bug to mark as blocking this!

Comment 11

[Justin Scott [:fligtar]]

This will be fixed in remora, but ok!

Comment 12

[Justin Scott [:fligtar]]

Remora does not use the same queue format.