Closed
Bug 582135
Opened 15 years ago
Closed 15 years ago
Move the Web Console filter box to the right
Categories
(DevTools :: General, defect)
DevTools
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: pcwalton, Assigned: pcwalton)
References
Details
(Whiteboard: [kd4b3])
Attachments
(1 file)
992 bytes,
patch
|
Gavin
:
review+
mossop
:
approval2.0+
|
Details | Diff | Splinter Review |
The Web Console filter box should be on the right, which both helps the "balance" of the design and matches the OS placement of search boxes on Windows and Mac.
This is a small, but important UI tweak to the Console, so I'm requesting approval for Firefox 4.
Attachment #460396 -
Flags: review?(gavin.sharp)
Comment 1•15 years ago
|
||
Requiring that we keep a reference to the DOM elements we're creating in makeHUDNodes so that makeFilterToolbar can append them is kind of silly. Can you refactor so that they're appended in makeHUDNodes instead, so that this can just use a local variable? You could even just inline makeFilterToolbar, since it only has the one caller...
(I wonder why we're dynamically creating the DOM here at all? I suppose it's because this component was designed to be app-agnostic? Even if we don't fix bug 579909, I wonder whether dynamically DOMParsing a static XUL file and inserting it into the document in one shot would be more efficient...)
Comment 2•15 years ago
|
||
(In reply to comment #1)
> (I wonder why we're dynamically creating the DOM here at all? I suppose it's
> because this component was designed to be app-agnostic? Even if we don't fix
> bug 579909, I wonder whether dynamically DOMParsing a static XUL file and
> inserting it into the document in one shot would be more efficient...)
I tried to create a console ui in markup a couple of times. The first approach was by placing the markup in browser.xul, with "display:none", then I would clone them and insert them in the tab. This did weird stuff, making it impossible to append logging nodes to the output node. Even people on the content team thought it was voodoo not worth trying to figure out.
I then looked at the way in which we dynamically apply overlays, but that won't work as it requires an id that is not dynamically generated.
There is a bug on making all of this UI into an XBL widget: bug 561458
Assignee | ||
Comment 3•15 years ago
|
||
(In reply to comment #1)
> Requiring that we keep a reference to the DOM elements we're creating in
> makeHUDNodes so that makeFilterToolbar can append them is kind of silly. Can
> you refactor so that they're appended in makeHUDNodes instead, so that this can
> just use a local variable? You could even just inline makeFilterToolbar, since
> it only has the one caller...
Created bug 582340 for this. The patch is attached there.
Updated•15 years ago
|
Attachment #460396 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Updated•15 years ago
|
Attachment #460396 -
Flags: approval2.0?
Updated•15 years ago
|
Attachment #460396 -
Flags: approval2.0? → approval2.0+
Assignee | ||
Updated•15 years ago
|
Keywords: checkin-needed
Comment 4•15 years ago
|
||
Comment on attachment 460396 [details] [diff] [review]
[checked-in] Proposed patch.
http://hg.mozilla.org/mozilla-central/rev/76cdb7d5f48c
Attachment #460396 -
Attachment description: Proposed patch. → [checked-in] Proposed patch.
Updated•15 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Whiteboard: [kd4b3]
Updated•15 years ago
|
Keywords: checkin-needed
Updated•7 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•