What should be implemented/improved? Currently there's no way for a Firebug extension to find out, if a CSS property name was changed. The only events fired are on removeProperty() and setProperty(). See https://groups.google.com/forum/#!topic/firebug/oJE32TF-THw for more info.

I already created a patch for this. Because 1.9 is already feature freezed, I'll apply it as soon as we have the 1.10 branch.

Sebastian

Applied patch in r12639.

Sebastian

Comment deleted

Nice! Thank you Sebastian

You're welcome, Johan. Happy New Year!

Sebastian

This issue (one of 9) has been fixed in Firebug 1.10.0a1 http://getfirebug.com/releases/firebug/1.10/firebug-1.10.0a1.xpi

Let us know if it works for you.

Thanks! Honza

Hello!

I can confirm that if you edit a css property "margin-left" => "margin-right" you end up with one delete event and one set event.

But by the code diff it seems like onCSSPropertyNameChanged should be fired? Tried to add a listener to that as well but that one was never triggered.

So if the fix is to call onCSSRemoveProperty when you change an existing property it all works fins!

The event is dispatched. I added some tracing info at r12683, so it can be seen in FBTrace. Note, that it is currently not part of the CSSModule like e.g. onCSSRemoveProperty, but of the CSSEditor. Because of that it seems, that you currently can't add listeners to it, which renders it useless.

So I assume I need to move the whole property name change code to the CSSModule to get this to work. If someone has a better idea, please let me know.

Sebastian

My comments:

1) I don't think we need to move the logic, it would be enough to distribute the event to proper listeners. See e.g. here: http://code.google.com/p/fbug/source/browse/branches/firebug1.10/content/firebug/editor/editor.js#634, inline editor is dispatching the event into the panel.

2) There are many events fired from Firebug editors, some of them to the panel, some to the module and some to the editor itself. We should document them and consequently decide what target object is suitable for the new event. Of course, the target object must be reachable by extensions to add/remove listeners.

3) I don't think this is something we want to port into 1.9

Honza

New features should not be ported into 1.9 branch.

(removing the port-1.9 label)

Honza

There are many events fired from Firebug editors, some of them to the panel, some to the module and some to the editor itself. We should document them... It would be very helpful, if all events were documented somewhere. The events currently dispatched when editing a CSS property inside the Style side panel are:

1. onInlineEditorShow => panel.fbListeners
2. onBeginEditing => Firebug.Editor.fbListeners
3. onCSSRemoveProperty => Firebug.CSSModule.fbListeners
4. onCSSSetProperty => Firebug.CSSModule.fbListeners
5. onCSSPropertyNameChanged => CSSEditor.fbListeners
6. onSaveEdit => Firebug.Editor.fbListeners
7. onStopEdit => Firebug.Editor.fbListeners
8. onBeforeCSSRulesAdded => CSSElementPanel.fbListeners
9. onCSSRulesAdded => CSSElementPanel.fbListeners

consequently decide what target object is suitable for the new event As comparison: The attribute editor dispatches an "onObjectChanged" event when saving the attribute to all Firebug.uiListeners. I doubt, that this is the right thing to do here. I'd say one of these would be the right choice: - panel.fbListeners (requires to listen to events coming from the CSS panel and the Style side panel separately) - Firebug.CSSEditor.fbListeners (requires exposing CSSEditor) - Firebug.CSSModule.fbListeners (requires moving the code to CSSModule)

Honza, what do you think?

Sebastian

The event is now dispatched to the CSSModule listeners. https://github.com/firebug/firebug/commit/8446d4b755bca317a149bf05ad4b147cb2319cb5

Sebastian

It would be nice to have docs + an example extension (within https://github.com/firebug/extension-examples repo) that shows how to properly use/handle all the events.

Honza

This issue has been fixed in Firebug 1.10.0a11 http://getfirebug.com/releases/firebug/1.10/firebug-1.10.0a11.xpi

Check it out and let us know if it works for you.

Thanks for the help! Honza

Mentioned the event at https://getfirebug.com/wiki/index.php/Extension_Migration_To_Firebug_1.10.

Sebastian

As extension authors are encouraged to base their extensions on Firebug 3 there is no need anymore for documenting the API of Firebug 2.

Sebastian