Closed Bug 667363 Opened 14 years ago Closed 7 years ago

id and class cells not invalidated when those attributes change

Categories

(Other Applications :: DOM Inspector, defect)

Product:
Other Applications
Component:
DOM Inspector
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: crussell, Unassigned)

Details

1. Inspect about:blank 2. Select the BODY element and choose "Inspect in New Window" (just to make sure the tree isn't getting repainted due to the insert/edit attribute dialog disappearing in the next step). 3. From the DOM Node viewer in the new object-only inspector, insert an attribute "id" with some non-empty value Expected results: The DOM Nodes viewer in the dual-pane inspector invalidates the id cell for the BODY row. Actual results: The cell is not invalidated, and the new value doesn't appear until the tree is repainted for unrelated reasons.
I believe have get expected results doing: A. Open DOM Inspector B. Type "about:blank" in the empty field to the left of the Inspect button C. Click Inspect button D. Navigate to "BODY" in the "Document-DOM Nodes" E. Click right and select "Inspect in New Window" F. On the new window, click right and select "Insert" G. On the dialog box, in Node Name, type "id" H. In Node Value, I typed "prueba" When clicked Ok, the new attribute appears in the main DOM Inspector window and the DOM Node opened window. I had no done any other swicth between window to avoid any possible repainting.
(In reply to Javi Rueda from comment #1) > When clicked Ok, the new attribute appears in the main DOM Inspector window In the document (left) pane, or in the object (right) pane? This bug is about how changing the class or id of an element doesn't update the class or id columns for that element in the document pane. If you do mean the document pane, it's possible that the cell is being invalidated for another reason, but the inDOMView implementation definitely does not invalidate attribute columns for mutations on those attributes. Here's another testcase: data:application/xhtml+xml,<html xmlns%3D"http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml"><head><%2Fhead><body><div id%3D"thediv"%2F><button onclick%3D'document.getElementById("thediv").setAttribute("class"%2C "hax")%3B'>do hax<%2Fbutton><%2Fbody><%2Fhtml> 1. Open the above page. 2. Open the DOM Inspector on that page. 3. Make sure that the "class" column in the document pane is showing. 4. Find the row for the "thediv" div. 5. Arrange your windows so your browser window is in the foreground, and so that you can click the button on the page without obscuring the class column and the "thediv" row with the window. 6. Click that button. Expected results: For the "thediv" row, the cell in the "class" column should immediately reflect the new value of the div's class attribute. Actual results: That cell only reflects the new value after the tree invalidates it for some other reason (mouseover, etc.).
(In reply to Colby Russell :crussell from comment #2) > (In reply to Javi Rueda from comment #1) > > When clicked Ok, the new attribute appears in the main DOM Inspector window > > In the document (left) pane, or in the object (right) pane? This bug is > about how changing the class or id of an element doesn't update the class or > id columns for that element in the document pane. Sorry. (re-)confirming the bug to myself, as what I saw in comment 1 was in right pane. In left pane on main window, the id is not inserted.
Status: NEW → ASSIGNED
Keywords: checkin-needed
Status: ASSIGNED → NEW
Keywords: checkin-needed
Bulk close. This component is no longer supported or maintained. https://bugzilla.mozilla.org/show_bug.cgi?id=1499023
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Bulk close. This component is no longer supported or maintained. https://bugzilla.mozilla.org/show_bug.cgi?id=1499023
You need to log in before you can comment on or make changes to this bug.