Open Bug 895893 Opened 11 years ago Updated 2 years ago

Add break on cookie change

Categories

(DevTools :: Storage Inspector, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: miker, Unassigned)

References

(Blocks 3 open bugs)

Details

(Whiteboard: [polish-backlog][todo-mr][t2])

Firebug has it so it must be possible.
Priority: -- → P3
Whiteboard: [devedition-40]
Whiteboard: [devedition-40] → [polish-backlog]
See Also: → dbg-dom-bps
Blocks: firebug-gaps
See Also: → 1165010, 1267144
See Also: → 821610
Component: Developer Tools: Netmonitor → Developer Tools: Storage Inspector
Whiteboard: [polish-backlog] → [polish-backlog][todo-mr]
Whiteboard: [polish-backlog][todo-mr] → [polish-backlog][todo-mr][t2]
Severity: normal → enhancement
Product: Firefox → DevTools

I was having a look at Firebug's code again in order to get to know how it worked there.

The logic there was basically like this:

  1. Listen for the cookie-changed event of the nsIObserver interface (like the Storage Inspector does).
  2. Call the panel-specific logic to stop the script execution.
  3. Check whether there's a breakpoint set.
  4. Call the general logic to stop the script execution.
  5. Stop at the currently executed stack frame.

As far as I can see, there is no direct connection between the cookie-changed event and the executed JavaScript statement, which might be a problem in the Fission-enabled world. So there could be the need to attach some stack frame related information to that event.

Honza, if I remember correctly, you were deeply involved in the debugger and Cookies panel code back then, so maybe you can tell more about this and whether there is a direct connection between those which can be used to implement this.

(This information will also be required for bug 1350812.)

Sebastian

Flags: needinfo?(odvarko)
See Also: → 1350812

Ah, I recall that code :-)

I think you summarized that pretty well.

As far as I can see, there is no direct connection between the cookie-changed event and the executed JavaScript statement,

If JS stack was available when we were handling "cookie-changed" event (i.e. the change was originated in JS) it was possible to break in the newest JS frame using Firebug.Breakpoint.breakNow - that how it worked back then - since the event was synchronous. Of course this might be different now when Fission is in place.

In any case, in order to implement this we need synchronous "change" event ensuring that the current JS stack is still available and we can pause JS execution at the very moment when cookie change is happening. Similarly to what we do for Break on XHR.

Honza

Flags: needinfo?(odvarko)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.