Correction of 4a. ..... do not save.

>Additionally, would we also want to save automatically when modifying the style
>via the UI and the HTML file is unmodified in the editor?
+1

Moreover I think we could save it even if modified as user may always undo the changes.

The disappearing content of the selection tab is AFAIK related to the navigator's selected node - once you change the class name the navigator shows the current tag as "not in DOM" so the selection view stops working. Once saved the node is refreshed and selection view works again.

I can make the create rule dialog saving the changes in any case, but this wouldn't fix the scenario when the source code is modified via editor of course. I think that Petr's proposal for the mesaage in the selection section sounds good.

Or would we also want to improve the diff algorithm in navigator to treat the original element and the modified element as one? Would that help?

I belive Honza Stola is the right person to answer that question, but I'd say no. Since the DOM tree in the browser wouldn't contain the information (would still point to the old class) we would get the Selection show something, but hardly correct.

I don't see much to improve in this test-case. The user modified the document/element in a significat way with respect to styling of the modified element. This change is not present yet in the browser. Hence, the CSS Styles view cannot show anything reasonable for the modified element. The user should save the document to see the change in the browser and a reasonable data in the view.

I like the idea of saving the document when it is modified using the 'Modify Rules' dialog. This should help in Scenario 1.

I agree with Marek that it doesn't help much to modify the diff algorithm to merge the 'old' and 'new' elements. In fact, this could be even more confusing because it hides the fact that the element in the editor is different from the element in the browser.

I don't like the idea of "you modified the document" warning. It is not needed in Scenario 1 (once the dialog is changed such that it saves the document) and it is silly in Scenario 2 to warn user that (s)he has modified the document when (well) (s)he has modified the document.

I am reassigning this issue to Marek to add the saving into the 'Modify Rules' dialog and I suggest to close this issue afterwards.

> I  suggest to close this issue afterwards

I disagree. Because right now in both scenarios the CSS Styles window says <No Element Selected>, which is just incorrect. And this will not be fixed by Marek's fix in case of scenario 2. 

> I don't like the idea of "you modified the document" warning. ... it is silly in Scenario 2 

Maybe it's silly, but it's still beter than displaying incorrect information, which is the current state. If we don't like it, let's think of better wording. But the current situation is a clear bug. 

So how about just "Save [file name] to see the styling view for this element." ?

I would prefer that we actually talk through this issue together before moving forward.

changeset:   239908:44f44345ad8e
summary:     CSS source model always saves the modified document if it hasn't been already modified before applying the changes. "Edit CSS Rules" does save the changes done to the file where the active html source element comes from in the same way.

I've done some sanity testing and the functionality possibly affected by this (mosty the first change) seems to work fine.

(In reply to comment #9)
Just to make it clear - since this change any modification done via the css source model will save the corresponding file if it hasn't been already modified before. 

So for example if you add or edit some properties vis the rule editor (bottom section of CSS Styles window) you'll get the css file saved after each modification. If you manually modify the file but not save it and then operate in the rule editor, the file will not be saved. The "CSS Live Update" still works in both cases so the browser content is always refreshed.

Thanks Marek, so the incorrect label is the one remaining problem, right?

Cc'ing also Honza Stola - Honzo please see my comment 7.

Liza, I would prefer to get closure on all P2 bugs including this one ASAP, as there isn't much time left before code freeze - especially considering the the need to fix ~100 bugs in the Easel area per week. Which aspects of this bug do you expect to be controversial or unclear?

Passing back to Honza as the possible fix of the "<No Element Selected>" issue upon class/id change of an html source element belong to the "selection panel".

What about showing:

The inspected file has changed,   
you need to save it to continue inspection.

+------+
 |   Save  |
 +------+

if we detect that the selected element has no DOM counterpart (grayed) while the file is already inspected?

Please note that the same problem does not happen for the change source element itself but for the whole subtree.

I am afraid that all the suggestions for the 'Save the file' label/warning are too tight to this test-case. Note that the main issue as I understand it is the following: User places a caret into an element (or selects this element in Navigator) that is not present in the browser. CSS Styles view shows "<No Element Selected>" which is not 100% accurate because there is some element selected in the Navigator.

First of all, this problem has nothing to do with file modification. The same will happen when the element is removed/modified by JavaScript. It is pretty common for a CSS class to be added to an element as a result of a user gesture in the browser (for example, to emphasize the element somehow activated by the user). It would be really misleading to tell the user to save the file in this situation.

The "<No Element Selected>" message in fact means that no element is selected in the browser (there may or may not be an element selected in the Navigator and if there is something selected in the Navigator then we just weren't lucky enough to find the corresponding element in the browser). We can somehow change the "<No Element Selected>" string to reflect this subtle difference.

Maybe the optimal solution would be to display "<No Element Selected>" only if there really is no element selected in Navigator and show something like "<Element not Found in the Browser>" if there is some element selected in Navigator and our diff algorithm did't match it with an element in the browser.

I would like to avoid showing any type of 'save the file to see more' warning because the file modification is independent from the mentioned problems. The file doesn't have to be modified to encounter the described situation. On the other hand, the inspection will show the correct information for majority of elements (sometimes for all) even when the file is modified. Moreover, it is just a blind guess that saving of the file will change the information for the selected element.

Sure, when an element selected in Navigator is not found in browser and the file is modified then we can show (besides "<Element not Found in the Browser>") a Save button and a message telling that the file was modified and that it may help to save the file to see the styling information for the element, but this seems really odd to me. It feels more like UI cluttering than a solution to a problem to me. I doubt that a user that modifed some element and haven't saved the file yet will be confused by the "<Element no Found in the Browser>" label and that (s)he needs more hints and an explicit Save button in CSS Styles view. If there is a need for this button in CSS Styles view then why don't include such buttons into all other views that may show inaccurate information. You may argue the same way to show Save button in Navigator when it shows a structure of a modified file and the diff algorithm is not able to match some source elements with browser elements. I believe that noone wants a Save button there. Hence, why to include it in CSS Styles view?

BTW, do you really consider this subtle problem to be a P2 issue?

>Maybe the optimal solution would be to display "<No Element Selected>" only if
>there really is no element selected in Navigator and show something like
>"<Element not Found in the Browser>" if there is some element selected in
>Navigator and our diff algorithm did't match it with an element in the browser.

That would be IMHO solution satisfactory enough. I believe user would understand why the UI can't  show anything upon s/he changed the class/id of an element.  

I agree that the SAVE button may be confusing as it may not always help to resolve the issue.

I agree that changing the label could be an improvement - probably sufficient for 7.3. Let's do it.

Honzo, thanks for the detailed explanation - in the future we may want to think more about this, especially the case you pointed out when the style class was changed by JavaScript. BTW, it sounds like the original DOM Tree component did not suffer from this problem (because it did not attempt to merge the tree with the source), no?

> BTW, do you really consider this subtle problem to be a P2 issue?

I think this was a P2 mainly in the context of scenario 1. I think after changing the misleading label, we can treat this issue as fixed and regard any additional improvements as separate bugs/enhancements.

I have implemented the suggested change, i.e., CSS Styles view shows "<No Element Selected>" when there is no element selected in Navigator and it shows "<Element Not Found in the Browser>" when the element selected in Navigator cannot be mapped to an element in the browser.

Modified files: http://hg.netbeans.org/web-main/rev/18fa36ea4042

If you encounter another problem with the mentioned test-case then please fill a new issue as this one is getting bloated a bit and it mixes few problems already. Thank you in advance.