When editing a node as HTML in the markup-view, changes should be previewed live, like in Firebug

ASSIGNED
Assigned to

Status

()

Firefox
Developer Tools: Inspector
P2
normal
ASSIGNED
3 years ago
a month ago

People

(Reporter: pascalc, Assigned: zer0)

Tracking

(Blocks: 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [btpp-fix-later])

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(4 attachments)

Steps to reproduce:

1/ right-click on text in the page -> inspect element
2/ in devtools pabel, right-right -> 'Edit as HTML'
3/ Change some text in the form open in devtools

Expected behaviour:
Text is updated on the page (like in Firebug)

Actual behaviour:
Nothing happens. The only way to see that reflected is to click somewhere else in the dom tree which means that:
- The html node I was working on is no longer selected
- I have to use the mouse/touchpad while I was in typing on keybpard because there is no key that will get me our of the form fill.

That makes the devtools cumbersome to test text changes on a page.
s/get me our of the form fill/get me out of the form field/
(In reply to Pascal Chevrel:pascalc from comment #0)
> Nothing happens. The only way to see that reflected is to click somewhere
> else in the dom tree
There's another way though: cmd/ctrl+ENTER.
It's not very self explanatory, but it's a way better than clicking on another node.

Live editing HTML might be a good idea indeed, but I don't see how it solves your original problems:
> - The html node I was working on is no longer selected
> - I have to use the mouse/touchpad while I was in typing on keybpard because there is no key that
> will get me our of the form fill.
The (In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #2)
> (In reply to Pascal Chevrel:pascalc from comment #0)
> > Nothing happens. The only way to see that reflected is to click somewhere
> > else in the dom tree
> There's another way though: cmd/ctrl+ENTER.
> It's not very self explanatory, but it's a way better than clicking on
> another node.
> 
> Live editing HTML might be a good idea indeed, but I don't see how it solves
> your original problems:
> > - The html node I was working on is no longer selected
> > - I have to use the mouse/touchpad while I was in typing on keybpard because there is no key that
> > will get me our of the form fill.

I don't really have a problem as I mostly use Firebug, but I could also have said that to edit a word in a sentence with Firebug it's 3 clicks while it's a 6 clicks with Firefox devtools. Individually all these small annoyances may seem unimportant to you but when you add them up, they are why I still prefer to use Firebug over the built-in dev tools, editing is just more straightforward than with the built-in tools.
No they definitely are important to me, no worries there!
For info, we have a firebug-gaps bug (bug 991806) that we use to try and get rid of all these annoyances.

I was just wondering how live editing would solve the 'getting out of edit mode' problem, that's all. It seems it does not, but that doesn't mean we shouldn't work on it.

I'll file another bug to work on improving the ux when editing HTML.
Blocks: 991806
OS: Linux → All
Hardware: x86_64 → All
Updated summary to clarify what exactly is meant by "live editing" in this context.
Summary: Html editing should be live editing, like in Firebug → HTML edits should apply after each key press, like in Firebug
See Also: → bug 815464
Triaged.
Updated the summary to differentiate it more easily from bug 815464.
Priority: -- → P2
Summary: HTML edits should apply after each key press, like in Firebug → When editing a node as HTML in the markup-view, changes should be previewed live, like in Firebug
Whiteboard: [btpp-fix-later]

Comment 7

8 months ago
FWIW, live edit preview in FireBug was the main reason I used Firefox over Chrome. As a web developer and designer, I relied on Firebug's Live Edit feature to quickly try out different UX ideas and immediately see the results. This allowed much faster iteration without having to click 4+ times (more if you need to scroll) to see the results of each change. It's common for me to try 50+ different variations before settling on the "best" option. So for me it's a big productivity loss for this feature to be gone.

Here's more context about the FireBug live edit feature to consider as you address this gap in FF dev tools:

1. There was an edit button on the toolbar-- very helpful for discoverability and is one less click than the right-click menu. There's lots of space next to the "plus" (new node) icon now. How about putting an edit button there?

2. Edit Mode in Firebug was a separate pane. This was much easier to use than the current "inside the inspector" editor, for a few reasons. First, editing longer content was easier and faster because you get the full height and width of the pane and don't have to scroll the inspector window to see the entire HTML you're editing. Second, you never had to worry about being kicked out of edit mode by accidentally clicking on another element. Third, it was (IMHO) a cleaner experience because you were either in "edit" or "not edit" mode-- so you could tell with a glance which mode was active.

Please restore this important feature soon!
(Assignee)

Updated

5 months ago
Assignee: nobody → zer0
Status: NEW → ASSIGNED

Comment 8

5 months ago
(In reply to Justin Grant from comment #7)
> FWIW, live edit preview in FireBug was the main reason I used Firefox over Chrome.
Thank you Justin for explaining why this feature is so important for a web designer.

I am currently using Pale Moon with Firebug to get this feature back, but there are other problems (outdated rendering) with that solution.

Please fix this.

Updated

4 months ago
Blocks: 1267303
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
You need to log in before you can comment on or make changes to this bug.