361495 - Advanced Property Editor should "propose" values

Status: RESOLVED FIXED

(SeaMonkey :: Composer, defect)

Description

[Ricardo Almeida]

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

Advanced Property Editor could be more user-friendly by adapting the input field of the Value.

Reproducible: Always

Steps to Reproduce:
1. Right-click on a tag (in status bar, ex: body)
2. Select "Advance Properties"
3. Pick an attribute

Actual Results:  
Value is just a text field

Expected Results:  
Value should adapt to the required type. If it's a color it should allow to select a color through color picker, etc...

Comment 1

[Serge Gautherie (:sgautherie)]

Can you reproduce with SeaMonkey v1.1.9 ?

Comment 2

[Ricardo Almeida]

(In reply to comment #1)
> Can you reproduce with SeaMonkey v1.1.9 ?

I don't know exactly what you want with this question (ex: knowing that I'm still alive and wish this feature ;)), but yes I can reproduce it as it was not yet implemented...

Comment 3

[Ian Neal]

Attachment: Fix advanced property editor

This patch:
* Makes the onChangeHTMLAttribute, onInputHTMLAttributeName and onInputHTMLAttributeValue functions take an argument and change js/xul to use them that way.
* Get onInputHTMLAttributeName to call onInputHTMLAttributeValue with the new value.
* Add onselect triggers to menulists to update the tree.

Comment 4

[[e-mail]]

Comment on attachment 549753 [details] [diff] [review]
Fix advanced property editor

So, the old code relied on old behaviour in that changing the focused element's value in script would still trigger input and change events. This no longer happens. To replace the input events you've used select events, although technically command events would be superior. To replace the change event you've forced the attribute to get set when picked from the menulist, but I'm not convinced that's a good idea, although I don't have a better idea than making no change and requiring the user to re-select the suggested value.

The rest of the patch appears to be irrelevant.

Comment 5

[[e-mail]]

(In reply to comment #4)
> I don't have a better idea than making no change and requiring the user to
> re-select the suggested value.
Well, I guess we could stop suggesting a value...

Comment 6

[[e-mail]]

Attachment: Possible patch [Checked: trunk Comment 8 & comm-aurora Comment 12]

Comment 7

[Ian Neal]

Comment on attachment 550368 [details] [diff] [review]
Possible patch [Checked: trunk Comment 8 & comm-aurora Comment 12]

r=me, the main difference between this and what I'd started to come up with was the changes to the xul

Comment 8

[[e-mail]]

Pushed changeset a0adbb4addc8 to comm-central.

Comment 9

[Joe Sabash [:JoeS1]]

Is this common code with mailnews "AdvancedProperty Editor?
If so, don't have a clue on what to look for given:
Bug summary="should propose values" vs. comment 5

Comment 10

[[e-mail]]

On old versions of Gecko, Composer's Advanced Properties dialog (also available in some places in HTML compose) would detect a selection from the attribute menulist and if it was one of a small set of known attributes (e.g. dir) then it would suggest a value from an editable menulist rather than the simple input field used for most attributes.

At some point the rules for change events on focused text elements whose value was changed by script changed and the dialog was no longer able to detect a selection from the menulist, allthough it was still able to detect an attribute name that was manually typed in.

This patch allows it to detect a selection from the menulist again although I wasn't able to completely duplicate previous behaviour in which the editable menulist would suggest a default value which would then be copied to the tree if the attribute was not immediately modified.

Comment 11

[Ian Neal]

Comment on attachment 550368 [details] [diff] [review]
Possible patch [Checked: trunk Comment 8 & comm-aurora Comment 12]

This would be good to get on comm-aurora too.

Comment 12

[Ian Neal]

Comment on attachment 550368 [details] [diff] [review]
Possible patch [Checked: trunk Comment 8 & comm-aurora Comment 12]

http://hg.mozilla.org/releases/comm-aurora/rev/a9f91402bf4c