Open Bug 1242029 Opened 4 years ago Updated Last month

[meta] Shape Path Editor -- (for CSS shape-outside & clip-path)

Categories

(DevTools :: Inspector, enhancement, P2)

enhancement

Tracking

(relnote-firefox 62+, firefox62 affected)

Tracking Status
relnote-firefox --- 62+
firefox62 --- affected

People

(Reporter: jensimmons, Unassigned)

References

(Depends on 24 open bugs)

Details

(4 keywords, Whiteboard: [DevRel:P1][designer-tools])

Attachments

(1 file)

As I've been teaching folks about CSS Shapes (level 1, the shape-outside property that allows a developer to wrap text around an image in a circle, polygon or other non-rectangular shape, among other things) — I've been demonstrating the tool that Razvan Caliman created for Chrome. It's a plugin, not shipped with Chrome Dev Tools, but it's easy to install and it's awesome. 

Well, the UX of the tool itself could be much better, but the capability is amazing. People gasp aloud when they see it in action. 

http://razvancaliman.com/writing/css-shapes-editor-chrome/

Firefox/Gecko does not support Shapes yet (https://bugzilla.mozilla.org/show_bug.cgi?id=1098939), but hopefully that will change. When it does, it would be awesome to have a tool like this baked into Firefox Dev Tools. 


(BTW, this ticket is not a duplicate of #1069485, which has a similar name, but is about making an editor tool for SVG.)
Component: Developer Tools → Developer Tools: Inspector
Thanks for filing Jen. This was definitely on my mental list of things to do whenever we did support css shapes.
Razvan's plugin is awesome indeed. We met in London in 2014 and talked about the various devtools APIs we had available to support this kind of plugin, but I haven't heard since.
I do agree that this makes sense as a built-in feature. It's one of those things that just makes sense, because it simplifies writing CSS. It makes it possible to write CSS visually.
Depends on: shape-outside
Depends on: css-shapes-1
I gathered together feedback I got about CSS Shapes while presenting at conferences. It'll give you a sense of the excitement for Shapes and for such a Dev Tool. People were gasping when I demoed the Chrome tool — gasping aloud in mass. (And then laughing at each other for all freaking out together.)

https://storify.com/jensimmons/desire-for-css-shapes
I'm pouring on Clip-path this week, and I keep wanting to use the CSS Shapes (add-on) tool in Chrome to edit my Clip-path. Which it doesn't do. 

It occurs to me that perhaps the technology is in fact linked, and we could create one tool that would do both — let a developer edit a shape for either shape-outside or clip-path. That would be very useful. And a way to make a compelling experience that's not available elsewhere. 

Work on clip-path is underway, and I hear, likely to land in FF47. Perhaps a such a tool could ship soon after?
Summary: CSS Shapes Editor tool → Shapes Editor tool -- for shape-outside & clip-path
I think it shouldn't be too hard to create the shape editor itself. Mind you, it's going to take time to get right, but at least we do have what's needed to get it done, and either me or Matteo (:zer0) would be good mentors for this (I'll set myself as a mentor for now, we can change later if needed).

It doesn't look like we have the resources in the team in Q1 to get this started though, but again, we can mentor people who might be interested to work on this.

The part that I'm less confident about though is the UX that ties the inspector and the shape editor. I'd like Helen's advice on this.
One simple approach: say you have a shape-outside property in the css rules panel, then maybe next to its current value, there should be a button that, when clicked, toggled the shape editor in the page.
Should this button always appear though (knowing that shape-outside can take very different values, from circle, ellipse or polygon, to url, or margin-box, ...)
Mentor: pbrosset
Flags: needinfo?(hholmes)
Note that the author of the add-ons for Chrome has expressed some interest in porting it to Firefox: https://twitter.com/razvancaliman/status/699251601006055425

Maybe a potential mentee if somebody reach out to him?
Hi! I'm the author of CSS Shapes Editor. I'm really glad to see interest in this.

I'd like to have a look and understand how complex it would be to port that editor for Firefox DevTools.

There's a standalone library for the shapes editor: https://github.com/adobe-webplatform/css-shapes-editor
It is externalized from the Chrome extension for reusability. In theory, it should be possible to use that library anywhere. However, the code wasn't maintained and there's a bug in the Snap.SVG library embedded within which causes it to fail in Firefox. I was hoping to rewrite it to avoid bundling Snap.SVG to reduce size and unnecessary complexity, but life moved on. 

I'll revisit the code to asses how feasible it is to fix.

@Jen: The Chrome CSS Shapes Editor works on -webkit-clip-path properties. Chrome APIs have subtly changed and the extension may fail to run sometimes. A quick workaround is to reload Chrome DevTools and it should be possible to edit shape properties that you want to take over in Firefox and test. Perhaps that helps as a temporary solution.

Regarding the UX for the Chrome extension, I agree it's not very practical. I welcome suggestions and help. There isn't a way to extend the Styles panel in Chrome (aka CSS Rules panel in Firefox). That's one API I'd love to have as an extension developer. I have yet to look into Firefox add-ons to see if it's possible for an add-on to extend the CSS Rules panel with UI for triggering an in-context editor on the inspected page. 

BTW, is there a strong reason why this shapes editing must be in Firefox DevTools rather than an add-on?
Just saying "the UX of the tool could be better" is lazy. So I made a video explaining what works well, and what I find a bit confusing. I'm imagining a lot of the choices were made due to 1) time, of course, and 2) the limitations of creating an add-on (as opposed to an integrated tool). 

Here's the video: https://vimeo.com/155903841


> BTW, is there a strong reason why this shapes editing must be in Firefox DevTools rather than an add-on?

I would love to see it as a building it tool, because I think Shapes is important, and will be popular. And making something that's an add-on will naturally have less traction. It's hard for people to find add-ons. Having something already baked into Dev Tools means it's already right there. Developers who don't even know Shapes exists are likely to stumble across a built-in tool, start playing around, and have their minds blown.

Also, we here at Mozilla are always looking for great additions to Firefox Dev Tools, and I believe this could be one.

Is there a reason Razvan that you would like it to not be built in, and prefer an add-on?

(In reply to Jen Simmons [:jensimmons] from comment #7)
> Just saying "the UX of the tool could be better" is lazy. So I made a video
> explaining what works well, and what I find a bit confusing. I'm imagining a
> lot of the choices were made due to 1) time, of course, and 2) the
> limitations of creating an add-on (as opposed to an integrated tool). 
> 
> Here's the video: https://vimeo.com/155903841

I guess what you couldn't figure out is that a shape can't extend beyond the bounding box of an element.

I also saw few smaller and bigger tedious things when working with the tool. Though I guess some of them may be specific to the Chrome implementation.
Probably those issues should be collected in the issue tracker for the tool[1], right? (asking everyone)

> > BTW, is there a strong reason why this shapes editing must be in Firefox DevTools rather than an add-on?
> 
> I would love to see it as a building it tool, because I think Shapes is
> important, and will be popular. And making something that's an add-on will
> naturally have less traction. It's hard for people to find add-ons. Having
> something already baked into Dev Tools means it's already right there.
> Developers who don't even know Shapes exists are likely to stumble across a
> built-in tool, start playing around, and have their minds blown.
> 
> Also, we here at Mozilla are always looking for great additions to Firefox
> Dev Tools, and I believe this could be one.
> 
> Is there a reason Razvan that you would like it to not be built in, and
> prefer an add-on?

One reason to add this feature as an extension is that the tool will probably only target a small group of people and otherwise clutters the UI.
There were already some discussions between the DevTools team and the Firebug team some time ago about making the DevTools hint about add-ons in specific contexts. E.g. in this case, when an element has a shape, the user would get a message along the lines of "Did you know there's a tool that can help you modify those shapes?" offering a simple way to install the related add-on. Unfortunately I couldn't find a related bug report for that. There is one for the built-in tools, though, which is bug 1239859.

(In reply to razvan.caliman from comment #6)
> Regarding the UX for the Chrome extension, I agree it's not very practical.
> I welcome suggestions and help.

One solution for an entry point I can think of is a little icon besides the 'shape-outside' and 'clip-path' properties within the Rules side panel like its already available for colors, timing functions, filters, etc. Clicking the icon would open a tooltip offering you to create a new shape (like its done in Chrome). Though, unlike the other tooltips, this would then allow you to edit the shape directly inside the page.

To make this non-destructive, you should always be able to press Esc while editing to restore the previous shape.
Regarding Jen's suggestion about being able to toggle between different options, there might be a UI added to store different shapes similar to the presets feature of the filters editor[2]. This might be available as an option within the tooltip (like for filters), or a UI besides the shape within the page, or a combination of both.

> There isn't a way to extend the Styles panel
> in Chrome (aka CSS Rules panel in Firefox). That's one API I'd love to have
> as an extension developer. I have yet to look into Firefox add-ons to see if
> it's possible for an add-on to extend the CSS Rules panel with UI for
> triggering an in-context editor on the inspected page. 

The tools can definitely be extended. See the points under 'EXTENDING THE DEVTOOLS' at the DevTools documentation[3] and especially Firebug 3[4].

Sebastian

[1] https://github.com/oslego/chrome-css-shapes-editor/issues/
[2] https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector/How_to/Edit_CSS_filters#Saving_filter_presets
[3] https://developer.mozilla.org/en-US/docs/Tools
[4] https://github.com/firebug/firebug.next
@Jen, thank you so much for taking the time to record that video!

I'm so sorry for the terribly inconsistent editor loading. I observed it happening now and then, but I didn't think it was this bad. That's a pain to use. I will look into it ASAP. It probably has to do with the circus that is the messaging workflow between the Chrome DevTools extension page <-> background Page <-> contentscript.

I'll go over the UX issues point by point:

- "Shapes" panel 
Chrome DevTools extensions don't provide a way to add a trigger next to CSS values in the Styles panel, like the color picker icon, timing function editor icon, and so forth. I couldn't commit to building the shapes editor into Chrome DevTools itself, therefore I duplicated the part of the Styles panel that I needed into that new "Shapes" panel. Not very good UX, but it got me faster to the point of shipping the editor.

Like Sebastian mentions, I'd love to be able to provide custom editors for CSS values that the browser can display next to CSS declarations in the Styles panel (Chrome) / Rules panel (Firefox). Ideally, I'd want developers to be able to create "color pickers", "timing function editors", "filter editors" that integrate into DevTools as if they were built in.

Sebastian's idea of prompting users with contextual add-on recommendations is great. Easier said than done, I'm sure, but it would be a good way to surface add-ons & tools relevant to solving a specific use case, thus improving discoverability.

Looking over the Firefox DevTools docs, I don't see an API to extend the Rules panel like that. Perhaps I'm mistaken. If that's the case, please point me to the right docs (I do see the ability to add new separate Panels, but that's the same as Chrome DevTools). It's my understanding that the Firefox color picker, filter editor and timing function editor are all built-in.

This is on the wishlist, but instead of tool-tip editors or separate panels I envisage inline custom editors. Brackets had this and it proved very practical. A keyboard shortcut splits the code editor and injects UI for handing the focused property/value.

See: http://blog.brackets.io/2012/11/30/brackets-sprint-17-build/brackets-inline-color-editor/?lang=en
Watch: https://www.youtube.com/watch?v=Fqt5COpqLuU

It would be amazing to have multiple specialized editors open and used in conjunction for complex workflows, like CSS gradient editor + blend-modes editor. I have plenty of use cases. The visibility of inline editors wouldn't have to be limited to on-at-a-time, like tooltip editor.

- Shape container
Shapes are constrained by the reference box: margin-box (default for shape-outside), border-box, padding-box or content-box. Read an in-depth explanation: http://razvancaliman.com/writing/css-shapes-reference-boxes/ 

I meant to highlight the reference box into the editor, but I never got around to it (https://github.com/oslego/chrome-css-shapes-editor/issues). I agree it's important.

- Switching between shapes
It would be great to store previous shapes in the current editing session so the user can swap between them. A store for shapes is also cool, but I think that's a full feature in and of itself.

- Icons
Yes, icons are not very accurate. A pen tool is a bit misleading since it's not free-form drawing like Ps or Ai, but more like path editing for which you use the Pointer tool.

- Limited discoverability
The hidden gem of functionality is that you can actually hold down the Shift key and click the pointer icon while the editor is active and that will cycle though unit types (px, %, em, rem, etc.) converting the value. That's very useful, but the are no affordances for it in the UI. I'd love to read ideas for highlighting that feature in an unobtrusive way.


> Is there a reason Razvan that you would like it to not be built in, and prefer an add-on?
  
The Shapes Editor is quite big and bulky, unnecessarily so right now because of the Snap.SVG dependency. I'm worried about unnecessarily slowing down Firefox DevTools. The other (subjective) reason, is that I don't have any experience building for Firefox, but I'm comfortable writing JavaScript. Having the editor library external, like it is now, makes it easier to reuse in other browsers / tools. However, given the limitations inherent to extensions, it may make more sense to have this built into DevTools if that can be done in a performance conscious manner.
> Probably those issues should be collected in the issue tracker for the tool[1], right? (asking everyone)

That would be very welcome.

Chrome extension: https://github.com/oslego/chrome-css-shapes-editor/issues/
Shapes library: https://github.com/adobe-webplatform/css-shapes-editor

If it lives in the Chrome DevTools, it's the extension.
If it is overlaid onto the page, it's the shapes library.
(In reply to razvan.caliman from comment #9)
> Like Sebastian mentions, I'd love to be able to provide custom editors for
> CSS values that the browser can display next to CSS declarations in the
> Styles panel (Chrome) / Rules panel (Firefox). Ideally, I'd want developers
> to be able to create "color pickers", "timing function editors", "filter
> editors" that integrate into DevTools as if they were built in.
> 
> ...
> 
> Looking over the Firefox DevTools docs, I don't see an API to extend the
> Rules panel like that. Perhaps I'm mistaken. If that's the case, please
> point me to the right docs (I do see the ability to add new separate Panels,
> but that's the same as Chrome DevTools). It's my understanding that the
> Firefox color picker, filter editor and timing function editor are all
> built-in.

Correct, the existing tooltips are built-in.

I'm not too familiar with the exposed APIs myself. My guess is that there is currently no explicit API exposed for those icons and tooltips, so you'd have to add those by yourself.
What Firebug 3 does is basically hook into the panels, wait until everything is loaded and then adjust the DOM within them accordingly. Jan 'Honza' Odvarko (head of the Firebug Working Group) can tell you more about that.
You may also have a look at the code related to bug 1055181.

> This is on the wishlist, but instead of tool-tip editors or separate panels
> I envisage inline custom editors. Brackets had this and it proved very
> practical. A keyboard shortcut splits the code editor and injects UI for
> handing the focused property/value.
> 
> See:
> http://blog.brackets.io/2012/11/30/brackets-sprint-17-build/brackets-inline-
> color-editor/?lang=en
> Watch: https://www.youtube.com/watch?v=Fqt5COpqLuU

This sounds very good to me! Proper APIs to do so should be added in a separate bug, though.

> It would be amazing to have multiple specialized editors open and used in
> conjunction for complex workflows, like CSS gradient editor + blend-modes
> editor. I have plenty of use cases. The visibility of inline editors
> wouldn't have to be limited to on-at-a-time, like tooltip editor.

For a gradient editor see bug 706102.

> - Icons
> Yes, icons are not very accurate. A pen tool is a bit misleading since it's
> not free-form drawing like Ps or Ai, but more like path editing for which
> you use the Pointer tool.

Might be an adjustment handle with a line through it similar to what Inkscape has (second button of the left toolbar).

> - Limited discoverability
> The hidden gem of functionality is that you can actually hold down the Shift
> key and click the pointer icon while the editor is active and that will
> cycle though unit types (px, %, em, rem, etc.) converting the value. That's
> very useful, but the are no affordances for it in the UI. I'd love to read
> ideas for highlighting that feature in an unobtrusive way.

Cool! Really hard to find, though. Might get an extra button within the tooltip.

Sebastian
(In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #4)
> The part that I'm less confident about though is the UX that ties the
> inspector and the shape editor. I'd like Helen's advice on this.
> One simple approach: say you have a shape-outside property in the css rules
> panel, then maybe next to its current value, there should be a button that,
> when clicked, toggled the shape editor in the page.
> Should this button always appear though (knowing that shape-outside can take
> very different values, from circle, ellipse or polygon, to url, or
> margin-box, ...)
I think it would be nice to follow the pattern we've set up with colors, filters, etc., which is to say the small dot next to the rule. We might need to consider some sort of message to appear within the page itself to make it more obvious that by clicking this you're affecting the page itself, not triggering a tooltip, but that's just an implementation detail we can sort out.

I know there's some discussion around whether or not this should live as an addon or not; since shapes will be in spec, I think it makes sense for devtools to have them natively. If we do the above as the way to work with shapes I'm not worried about cluttering the UI, as I would be with with an extra panel. There is precedent for releasing things as addons first for testing, which might be worth considering, but additional debate notwithstanding I think getting this into devtools proper would be really cool. If we do go with an addon (for whichever reason), Sebastian's idea of a contextual prompt in the console is the way to go, I think.

I chatted with Patrick about this over IRC—I think that the circle that triggers the editor should always show on the shape-outside property (even for properties that wouldn't trigger any sort of editing tool in the page) and we should consider some sort of message like, "try shape-outside: circle to start".

(In reply to razvan.caliman from comment #9)
> This is on the wishlist, but instead of tool-tip editors or separate panels
> I envisage inline custom editors. Brackets had this and it proved very
> practical. A keyboard shortcut splits the code editor and injects UI for
> handing the focused property/value.
Since this is a pattern we see in a lot of places, I think it would be nice to come up with a solution for both inline editing and tooltips where relevant. Inline editing is great when you know what you're doing, the tooltips can be really good for play/discoverability.

> It would be amazing to have multiple specialized editors open and used in
> conjunction for complex workflows, like CSS gradient editor + blend-modes
> editor. I have plenty of use cases. The visibility of inline editors
> wouldn't have to be limited to on-at-a-time, like tooltip editor.
I would love to hear about all of these, so I'd love to follow up on this stuff!

> - Shape container
> Shapes are constrained by the reference box: margin-box (default for
> shape-outside), border-box, padding-box or content-box. Read an in-depth
> explanation: http://razvancaliman.com/writing/css-shapes-reference-boxes/ 
Sounds like maybe you could chop off the editable shape as it dips out of its viewbox, maybe?

> - Icons
> Yes, icons are not very accurate. A pen tool is a bit misleading since it's
> not free-form drawing like Ps or Ai, but more like path editing for which
> you use the Pointer tool.
I think Jen might have a good point that the pen tool will be the most recognizable here, though. Technically you're right—the empty arrow is used for editing, but you do have to switch back to the pen tool for adding points. The current editor seems to use one icon for both scenarios at present.

> - Limited discoverability
> The hidden gem of functionality is that you can actually hold down the Shift
> key and click the pointer icon while the editor is active and that will
> cycle though unit types (px, %, em, rem, etc.) converting the value. That's
> very useful, but the are no affordances for it in the UI. I'd love to read
> ideas for highlighting that feature in an unobtrusive way.
Sounds like something that might be useful elsewhere in devtools, too. I'll try and follow up on this as well.
Flags: needinfo?(hholmes)
Filter on CLIMBING SHOES
Priority: -- → P3
Whiteboard: [DevRel:P2]
Summary: Shapes Editor tool -- for shape-outside & clip-path → CSS Shapes Editor tool -- for shape-outside & clip-path
Summary: CSS Shapes Editor tool -- for shape-outside & clip-path → Shapes Editor tool -- for CSS shape-outside & clip-path
We [1] met 2 weeks ago in London to discuss the tooling for this in more details.
Here's a summary of what we discussed:

The implementation of CSS Shapes in Firefox just started. It should take a couple of quarters (Q4 2016?)
Devtools should aim at shipping something in Q4 2016 too.
Devtools can start already with clip-path which is supported already and has the same syntax.

We're aiming at creating a couple of new UIs for this:
- an in-page overlay tool that lets users change the shape by manipulating it in the page,
- an inline editor in the rule-view that appears below shape-inside, shape-outside and clip-path properties to toggle the overlay and control a few more things.

In the rule-view:
  - an inline editor opens below corresponding properties,
  - the editor allows to create a new shape by choosing circle, ellipse, polygon,
  - the editor allows to switch to shape or point edition mode,
  - it also allows to choose url() (which expects an image with an alpha channel used to determine the shape),
  - related nice-to-have: highlight the image's alpha channel in the page,
  - for shape-outside, the reference box can be changed (margin, content, ...)
    - highlight the reference box in the page,
    - display points that are outside of the box differently and show the shape as clipped,
    - allow to change the reference box,
  - the editor can also be used for properties inside @keyframes rules in the rule-view, since css shapes are animatable. If the animation is running, the in-page overlay shouldn't move, it should just represent the shape at that particular keyframe,
  - the editor provides a way to change units used for the points' coordinates all at once: convert all coordinates from px to % for example,
  - nice-to-have: hovering over coordinates in the rule-view highlights the point in the page
  - nice-to-have: hovering over a point in the page highlights the coordinates in the rule-view

Editing points in the page:
  - click to add a new point
  - remove points
  - move points
  - nice-to-have: snap to grid

Editing shapes:
  - move the whole shape at once (to avoid having to manipulate each point)
  - rotate the shape
  - scale the shape
  - translate the shape
  - nice-to-have: snap to grid
*
[1] Razvan, :helenvholmes, :jensimmons, :astley and I, if I recall correctly
Keywords: meta
Priority: P3 → P2
Depends on: 1282712
Depends on: 1282716
Depends on: 1282719
Depends on: 1282721
With the shipping of basic shapes support for clip-path property in bug 1247229, we are soon to be able to speed up the development of corresponding shape editor tool in DevTool.
I'm really looking forward to seeing this editor present in our DevTool.
Depends on: basic-shape-ship
Is there anyone actively working on the editor?
(In reply to razvan.caliman from comment #16)
> Is there anyone actively working on the editor?
No there isn't anyone right now.
As bug 1326409 has been landed, now we've had full support for <basic-shape> value for shape-outside property(As of FF55, pref-off) and clip-path property(As of FF54, pref-on).

That said, we still need tool side support to offer author a better tool for shape editing. No matter it's being built into DevTool or as a plugin like shape tool on Chrome, it would be a great experience for designers likewise.
Flags: needinfo?(pbrosset)
(In reply to Astley Chen [:astley] (UTC+8) from comment #18)
> Created attachment 8847411 [details]
> shape-outside-firefox55.png
> 
> As bug 1326409 has been landed, now we've had full support for <basic-shape>
> value for shape-outside property(As of FF55, pref-off) and clip-path
> property(As of FF54, pref-on).
This is awesome!
> That said, we still need tool side support to offer author a better tool for
> shape editing. No matter it's being built into DevTool or as a plugin like
> shape tool on Chrome, it would be a great experience for designers likewise.
It would, totally agree on this!
We don't have the bandwidth right now though. It's looking Q2 will be hard too. We're trying to finalize a few other things in the inspector, and a shapes editor would be a better candidate for Q3 possibly.
Flags: needinfo?(pbrosset)
Depends on: 1373339
Depends on: 1373817
Removing dependencies that I don't think applies
No longer depends on: 1258390, 1282712
Depends on: 1383866
Depends on: 1383870
Depends on: 1383874
Depends on: 1385398
Whiteboard: [DevRel:P2] → [DevRel:P1]
Depends on: 1405339
Depends on: 1411402
Depends on: 1411645
Depends on: 1412273
Depends on: 1412278
Whiteboard: [DevRel:P1] → [DevRel:P1][designer-tools]
Summary: Shapes Editor tool -- for CSS shape-outside & clip-path → [meta] Shapes Editor tool -- for CSS shape-outside & clip-path
Severity: normal → enhancement
Duplicate of this bug: 1169406
Summary: [meta] Shapes Editor tool -- for CSS shape-outside & clip-path → [meta] Shape Path Editor -- (for CSS shape-outside & clip-path)
Depends on: 1418066
Duplicate of this bug: 1047812
Depends on: 1419786
Depends on: 1419792
Depends on: 1424275
Depends on: 1424939
Depends on: 1435368
Depends on: 1435370
Depends on: 1435373
Depends on: 1436054
Depends on: 1438127
No longer depends on: 1438127
Depends on: 1438127
Depends on: 1443151
Depends on: 1450234
Depends on: 1450650
Depends on: 1450668
Depends on: 1450671
Depends on: 1450685
Depends on: 1450891
Depends on: 1450936
Depends on: 1450980
Depends on: 1451236
Depends on: 1451264
Depends on: 1451281
Depends on: 1451353
Depends on: 1451684
Depends on: 1451740
Depends on: 1452076
Depends on: 1452078
Depends on: 1452582
Depends on: 1453428
Depends on: 1454317
Blocks: 1455535
Depends on: 1455538
Blocks: 1455546
Depends on: 1455558
Depends on: 1455564
Blocks: 1455588
No longer blocks: 1455588
Depends on: 1455588
No longer blocks: 1455546
Depends on: 1455546
No longer blocks: 1455535
Depends on: 1455535
Depends on: 1456777
Depends on: 1452986
No longer depends on: 1452986
Depends on: 1457206
Depends on: 1457838
Depends on: 1462003
Depends on: 1462656
Depends on: 1464401
(no use setting the mentor field on this meta bug, furthermore, the work has been done already anyway)
Mentor: pbrosset
Depends on: 1468170
Depends on: 1468333
Product: Firefox → DevTools
Depends on: 1469332
See Also: → 1451642
Depends on: 1488159
Depends on: 1489637
Depends on: 1507103
Depends on: 1507749
Depends on: 1522557
Depends on: 1522806
Depends on: 1522808
Depends on: 1575186
Depends on: 1598104
Depends on: 1603066
You need to log in before you can comment on or make changes to this bug.