Closed Bug 657172 Opened 13 years ago Closed 13 years ago

Scratchpad context selection should conform to DOM Inspector context selection

Categories

(DevTools :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: erikvvold, Unassigned)

Details

(Whiteboard: [scratchpad])

DOM Inspector has "Inspect Chrome Document" and "Inspect Content Document" File menus which allow users to select exactly which context should be used. I'd like to see Workspace/Scratchpad conform.

We'd have to make two changes afaict:

1. Remove the "Context" menu
2. Rename the menuitems to say "Scratch Chrome Document" or "Use Chrome Document"
3. Provide menupopups for each menuitem which make it possible to select exactly which chrome/content document that the user wants to use.
hehe three*
Not sure I agree. I find DOM Inspector's "Inspect Chrome Document" menu confusing as it typically has entries like,

https://bugzilla.mozilla.org/show_bug.cgi?id=657172
about:blank
about:blank
about:blank
DOM Inspector
DOM

what are the three about:blank windows?

I think executing against the front-most tab or the browser window in the chrome case gets you enough. Easy enough to go from there to another chrome window if you need to via the nsIWindowMediator.
Summary: Workspace context selection should conform to DOM Inspector context selection → Scratchpad context selection should conform to DOM Inspector context selection
Whiteboard: [scratchpad]
(In reply to comment #2)
> Not sure I agree. I find DOM Inspector's "Inspect Chrome Document" menu
> confusing as it typically has entries like,
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=657172
> about:blank
> about:blank
> about:blank
> DOM Inspector
> DOM
> 
> what are the three about:blank windows?

Well I agree, that is an issue, but it's a marginal issue imo, usually page title's are unique enough to make sense. We can still provide the option of selected the most recent window as well (maybe we can simply indicate with menuitem is the most recent).

> I think executing against the front-most tab or the browser window in the
> chrome case gets you enough.

If you just want to try out some JS then it is enough, but if you want to try out some JS against a specific document then it means finding the right window then finding the right tab, then selecting the workspace window without touching another window.

> Easy enough to go from there to another chrome
> window if you need to via the nsIWindowMediator.

That's only for the chrome context.
Normally, modality is a bad thing and it's nice that the Scratchpad presently offers just one execution context for most users (content). But, it is worth thinking about this, because you might have some JavaScript snippets that are general jQuery bits that you use anywhere. More likely, however, is that you'll be trying out specific code for specific sites.

Often, when I'm working on a site or app, I'll have multiple tabs open looking at different parts of it. Perhaps we want the Scratchpad to be restrictable to sites like Greasemonkey... when you go to a tab for a different site, the Scratchpad disappears. (This thought is undoubtedly half baked.)
One more note: a "workspace" in Smalltalk land would live inside of an image. In the browser, the user gets into a new namespace each time they load a page... the mechanics feel a bit different, which is why it's worth thinking about them some more.

I'm sure we'll get more feedback and ideas when Scratchpad is in the wild.
I think for the initial release, it made sense to tighten up the current scoping model, i.e., tying it to a single tab. I'd love to experiment with different scoping though and think locking or pinning a scratchpad to a particular document makes sense in a lot of cases. I'm not sure I like the way DOM Inspector presents two file menus with cryptic titles/hrefs as its lookup mechanism though. It feels kind of primitive and slow in use.

Erik, addons and experiments are welcome!
that should have been "i.e., tying it to the active tab". See? I can't even keep it straight. :)
I think we're going to go with another solution for this. Closing.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.