12440 - Feature: Need a built-in inline editing capability

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Syd Logan]

We need some widget that has the ability to provide visual clues to the user
that it can be pressed (meaning, it should probably look like a titledbutton),
but can be configured dynamically to become an editable field. This is needed
for in-place editing of tree items in our particular case.

Comment 1

[Mike Shaver (:shaver emeritus)]

If we don't want to embed a webshell/editorshell in the edited button, we could
use a neat trick from the Gnumeric guys: create an invisible editor widget and
then proxy events to it, and observe content/selection.  Maybe it's no big
deal to put an editorshell in the button, or swap them out, or something.

Comment 2

[David Hyatt]

I believe this to be very low priority. Shoving off to M14.

Comment 3

[Peter Trudelle]

reassigning to shaver per hyatt

Comment 4

[Paul MacQuiddy]

spam: changing qa contact from ckritzer -> paulmac for xul bugs

Comment 5

[leger]

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.

Comment 6

[David Hyatt]

Taking back.

Comment 7

[Paul MacQuiddy]

qa to jrgm

Comment 8

[Peter Trudelle]

There is no cross-app demand for this, and we have no time to do it in the
current release.  resolving as later

Comment 9

[Alex Musil]

This functionality is needed for an important AIM beta 2 feature.  Reopening and 
requesting for the M15 or M16 milestone.

Comment 10

[Alex Musil]

The feature is inline editing of the buddy list, BTW.

Comment 11

[Peter Trudelle]

adding duration swag.  

Comment 12

[Peter Trudelle]

Mass moving M17 bugs to M18

Comment 13

[Peter Trudelle]

Mass-moving feature bugs back to M17

Comment 14

[David Hyatt]

...

Comment 15

[don]

Move to M20.

Comment 16

[Claudius Gayle]

inline editing for bookmarks in the treeview has been a product requirement (low priority) from the begining as well.

Comment 17

[Claudius Gayle]

*** Bug 38749 has been marked as a duplicate of this bug. ***

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

I don't know if in the Brave New World of ender lite my situation here is any 
simpler, but I tried to  knock together a primitive implementation of this 
some time ago with ender and the problem I ran into was that I had to 
specify a size (using the 'size' attribute) on the text field to get it to show up, 
and that left an awkwardly sized textfield whose width had no relation to 
the length of the element being inline-edited.

Maybe I was doing something wrong. This is a highly desirable feature, 
will have a look in the nsbeta3 timeframe. 

Comment 19

[johng]

nav triage team:
nsbeta3-
Desirable feature, but easy to live without (didn't have it in 4.x).  Bummer, 
but we got to ship this puppy.  Feature did not make it in time.

Comment 20

[Ben Goodger (use ben at mozilla dot org for email)]

I want to fix this for 1.0/6.5

Comment 21

[Blake Ross]

Inline editing has been implemented for trees and Ben has another bug to do it 
for outliners (patch attached).  Any more work needed here?