Closed Bug 509478 Opened 15 years ago Closed 15 years ago

Text editing broken in Firebug edit mode and other extensions

Categories

(Core :: Web Painting, defect, P1)

Product:
Core
Component:
Web Painting
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: rcampbell, Assigned: roc)

References

Details

(Keywords: regression, Whiteboard: [firebug-p1]) 

Getting reports that editing is broken in Firebug's HTML, Style and DOM editors. Also heard that Twitterfox is having a similar problem where the text input field isn't focusable.

STR:
1. Open Firebug on this or any page.
2. Go to the HTML panel, select a node with some attributes
3. Try to edit an attribute

What you'll see:
Editor widget pops up but you are unable to enter or modify text.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090804 Minefield/3.6a1pre
To work in Minefield, you can install firebug 1.5a20 available here:
http://getfirebug.com/releases/firebug/1.5X/
Flags: blocking-firefox3.6?
thanks!

Masayuki Nakano — Bug 125282 Webpage-JS can steal focus from URLbar / chrome r=enn, sr=smaug

looks suspicious.

http://hg.mozilla.org/mozilla-central/rev/8366e5cc9f57

deals with focusing elements.
Blocks: 125282
Given that that patch was backed out (see bug 125282 comment 73), seems pretty unlikely.  Assuming you're seeing the problem in builds more recent than last week's, of course.
There were some selector-matching changes in that range too that might matter.

Someone who can reproduce this should just bisect.
yeah, will do.
looks like it's one of the other changes.
No longer blocks: 125282
Are you using a deck?
Again, are you using a deck?
Blocks: 506615
Keywords: regressionwindow-wanted → regression
Blocks: 491553
(In reply to comment #11)
> Again, are you using a deck?

Yes, we're using three of them afaict. When I said "looks like" I was responding to you. I could have been clearer.

All in firebugOverlay.xul

<deck anonid="deck" id="fbPanelBar1-deck" flex="1">
                            <browser id="fbPanelBar1-browser"
                                     tooltip="fbTooltip" contextmenu="fbContextMenu"
                                     disablehistory="true"
                                     src="chrome://firebug/content/panel.html"
                                     role="tabpanel" />
                        </deck>

and ...

                    <deck id="fbSidePanelDeck" persist="width,height">
                        <panelBar id="fbPanelBar2" class="panelBar">
                            <hbox id="fbPanelBar2-tabBox" class="panelTabBox" collapsed="true">
                                <hbox id="fbPanelBar2-panelTabs" class="panelTabs" role="tablist"
                                      aria-label="firebug side panels" />
                            </hbox>
                            <deck id="fbPanelBar2-deck" flex="1">
                                <browser id="fbPanelBar2-browser"
                                         tooltip="fbTooltip" contextmenu="fbContextMenu"
                                         disablehistory="true"
                                         src="chrome://firebug/content/panel.html"
                                         role="tabpanel" />
                            </deck>

The text edit widget that gets created for the editor is a child of the tabpanel's content area.
Why are you using these random decks with only one child, if I might ask?  ;)

No idea what you mean by "tabpanel's content area" above.
You're asking me? I didn't design this thing! ;)

These things get populated dynamically at runtime. Why're they're decks I don't really know. I need to dig into these things deeper to actually understand what's going on.
A reduced testcase would be useful.
Whiteboard: [firebug-p1]
Component: Extension Compatibility → Layout: View Rendering
Flags: blocking-firefox3.6?
Product: Firefox → Core
QA Contact: extension.compatibility → layout.view-rendering
Flags: blocking1.9.2+
Priority: -- → P1
(In reply to comment #16)
> Do these builds here (from bug 511951) fix the problems?
> https://build.mozilla.org/tryserver-builds/rocallahan@mozilla.com-try-38477eaf4c9f/

That build fixes the issue for me.
Firebug 1.5x.0a21 / OS X 10.5.8
Can this marked FIXED now that bug 511951 has landed ?
At least with Firefug.latest and the most recent nightlies editing text works fine for me.
(In reply to comment #16)
> Do these builds here (from bug 511951) fix the problems?
> https://build.mozilla.org/tryserver-builds/rocallahan@mozilla.com-try-38477eaf4c9f/

nightlies on mozilla-central (3.7) have fixed this problem but it's still broken on 1.9.2. I guess we're waiting for that patch to land here?
(In reply to comment #19)
> nightlies on mozilla-central (3.7) have fixed this problem but it's still
> broken on 1.9.2. I guess we're waiting for that patch to land here?

Yes.
Looks like that bug landed on 1.9.2 on September 16.  Is this now working on 1.9.2?
Assignee: nobody → roc
I'm going to mark this FIXED by bug 511951.
Status: NEW → RESOLVED
Closed: 15 years ago
status1.9.2: --- → beta1-fixed
Resolution: --- → FIXED
(In reply to comment #21)
> Is this now working on 1.9.2?

Yes, I just verified it using a Namoroka nightly build [1] with Firebug 1.5X.0a24.

[1] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20090923 Namoroka/3.6b1pre (.NET CLR 3.5.30729)
verified this yesterday on Namoroka nightly with Firebug 1.5a24. Confirms what Helder saw.

Thanks, David and Roc.
Status: RESOLVED → VERIFIED
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.