Move the Web Console filter box to the right

RESOLVED FIXED

Status

RESOLVED FIXED
9 years ago
6 months ago

People

(Reporter: pcwalton, Assigned: pcwalton)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kd4b3])

Attachments

(1 attachment)

(Assignee)

Description

9 years ago
Created attachment 460396 [details] [diff] [review]
[checked-in] Proposed patch.

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)
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

9 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

9 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.
(Assignee)

Updated

9 years ago
Blocks: 559481
Attachment #460396 - Flags: review?(gavin.sharp) → review+
(Assignee)

Updated

9 years ago
Attachment #460396 - Flags: approval2.0?
Attachment #460396 - Flags: approval2.0? → approval2.0+
(Assignee)

Updated

9 years ago
Keywords: checkin-needed
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Updated

9 years ago
Whiteboard: [kd4b3]
Keywords: checkin-needed

Updated

6 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.