Closed Bug 573858 Opened 14 years ago Closed 14 years ago

changing an addon's name does not take effect until revision is saved

Categories

(Mozilla Labs Graveyard :: FlightDeck, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dietrich, Assigned: andy+bugzilla)

References

Details

1. clicking on your addon's name on the left side
2. change the title in the dialog
3. click ok to close the dialog

the displayed name is not changed. if you open the dialog the change does show up there. but if you reload the page, the changes are completely lost.

i think this should block, so we don't end up with a zillion "My Addon" addons.
It looks like changes to the Name and Description fields only take effect when you press the Save button.  Since those changes are not versioned, and the Save button is for saving changes that are versioned (which is why pressing the Save button creates a new revision), changes to the Name and Description fields should indeed take effect immediately.

I'm not sure this should block.  It sucks, but does it suck enough to rise to the level of a blocker (as opposed to something we should document in a release note) for this early preview?
Summary: changing an addon's name does not take effect → changing an addon's name does not take effect until revision is saved
The reason i thought it should block is because the "first impression" experience of Flightdeck: a bunch of "My Addon" addons. Not so exciting. Since this isn't public beta, yeah probably doesn't have to block.

WRT to a solution: I didn't get at all that it was tied to hitting save. I thought that those buttons were all about the code, since they're visually differentiated in the UI (different section, different look), and the addon info bit is in it's own dialog.

I'd prefer that the addon info fields apply when you hit "ok". If we do decide to keep it tied to the save button, then we should 1) unify those UI bits and 2) warn when the user makes changes and tries to leave the page without saving them.
Severity: blocker → major
(In reply to comment #2)
> The reason i thought it should block is because the "first impression"
> experience of Flightdeck: a bunch of "My Addon" addons. Not so exciting. Since
> this isn't public beta, yeah probably doesn't have to block.

Yeah, I'm undecided.  It's quite the pitfall.


> WRT to a solution: I didn't get at all that it was tied to hitting save. I
> thought that those buttons were all about the code, since they're visually
> differentiated in the UI (different section, different look), and the addon
> info bit is in it's own dialog.

Yes, your impression is actually correct with regard to the Name and Description, which are not associated with revisions (i.e. they are not versioned) and shouldn't have to be saved (instead, changes to them should take effect immediately).

The Version field is the one exception in the Edit Info dialog, since a change in the value of the Version field is associated with the next saved revision.  Piotr and I spent some time figuring out how that should work, and I think it works ok as it is, since if you don't press Save, the code changes to which the new version applies aren't saved either.

But it makes me wonder whether a change to the Version field should prompt an immediate save.  Alternately, as you suggest, we could integrate the Version field into the Save button.  I've mocked up an enhanced Save button with a dropdown marker for opening a popup that lets you specify a changelog comment, and we could probably integrate Version into that popup fairly easily.

And we should indeed warn users when they try to leave the page without saving changes.  We're currently prevented from doing that by a bug in the version of Bespin we are using that prevents us from finding out if the code has changed.  That's again something we'll want to fix for the next release.
Just for the record, there are now 20 pages or so of "My Addon" addons listed.
let's fix name and description here, and move the redesign of the version/revision stuff and the warn-on-change issue to other bugs. i'll file those.
filed bug 577736 for moving Version over to the save/revision area.

filed bug 577735 for warning the user when leaving the page without saving changes.
No longer blocks: 578542
Severity: major → normal
Priority: -- → P3
Target Milestone: -- → 0.6
Not stoked on downgrading severity of this bug. See comment #2 and comment #4. Paging through thousands of My Addon and My Library doesn't make a very good first impression of the site, and makes finding things impossible.
Dietrich! Buddy! I didn't want you to be all frowny faced about this bug, so at the same time I downgraded the severity, I also marked it for completion in this release cycle (we freeze the 15th of November) so take heart! :)
You've turned my frown upside down.
We will flag unsaved state with a color change on the save button to indicate that a save action is needed from the user.
Target Milestone: 0.6 → 0.7
Assignee: nobody → amckay
As a more robust solution, let's get the AMO username of the developer and save unnamed add-ons with this as the title then increment that so mine would be Dandonkulous, Dandonkulous(2), etc. This way unmodified packages are not flooding the page with the same names.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: Mozilla Labs → Mozilla Labs Graveyard
You need to log in before you can comment on or make changes to this bug.