307751 - Align has changed for textbox elements with 'type=autocomplete"'

Status: RESOLVED WONTFIX

(Toolkit :: Autocomplete, defect)

Description

[Colin Bleckner]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

It seems like elements inside a <textbox> element are sometimes right aligned,
although they were left aligned in earlier releases.  I think this is easier to
describe with an example (will attach a file).

Reproducible: Always

Steps to Reproduce:
1. View attached XUL file in Firefox Beta 1.


Actual Results:  
Image in text box is right aligned.

Expected Results:  
In Firefox 1.0 or in Deerpark alpha 2 the image is left aligned.  

If I remove the 'type="autocomplete"' from the textbox, the image goes back to
being left aligned.  If I remove the <hbox> element surrounding the <image>
element, the image goes back to being left aligned.

Comment 1

[Colin Bleckner]

Attachment: Test XUL file

Comment 2

[Colin Bleckner]

I just saw Asa's post about setting the blocking1.8b5 for Firefox 1.5 beta 2
bugs.  I think this might be one (as a regression from the alphas); setting
blocking1.8b5?.

Comment 3

[Asa Dotzler [:asa]]

Colin, can you look at nightly builds and find out when this changed? If we can
determime what build changed this, we can probably find the offending checkin
and get the right person looking into this. 

Comment 4

[Asa Dotzler [:asa]]

->toolkit

Comment 5

[Colin Bleckner]

This displays correctly (left aligned) in the 2005-08-11 mozilla1.8 nightly, but
moves to right aligned in the 2005-08-12 mozilla1.8 nightly (tested with
nightlies from: http://archive.mozilla.org/pub/firefox/nightly/).

Comment 6

[Uri Bernstein]

Confirming on OS X => All/All.

Comment 7

[Asa Dotzler [:asa]]

can someone poke at bonsai and see what checkins happened in that window so we
can get this correctly assigned?

Comment 8

[Colin Bleckner]

I've never looked at the mozilla source or used bonsai before, so this
information could be all wrong, but I figured I'd give it a shot.

I did a bonsai search in MozillaSource against the HEAD branch for all changes
between 2005-08-11 00:00:00 and 2005-08-12 23:59:59 (I'm not sure what time the
nightly builds start).  The resulting query
(http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaSource&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-11+00%3A00%3A00&maxdate=2005-08-12+23%3A59%3A59&cvsroot=%2Fcvsroot)
shows a few changes, but the ones that really stand out (to me) are the changes
for bug 299992.  There are 4 checkins for that bug then another to pull the
change out because of "too much odd platform-specific bustage."  I looked at
some of the diffs of the original changes and the revert changes and not all of
them are exactly the same.

Comment 9

[Mike Schroepfer]

Can we get a sense of impact here?  

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

That was right around when 1.8 branched -- it's not clear whether you should be
looking at trunk checkins or branch checkins.  And where did you get those
nightlies, exactly?  They do have build hours in the filename.

Comment 11

[Colin Bleckner]

Yeah, I noticed that it was right at the branch time, so I wasn't sure what code
to look at.  The nightly builds I grabbed were from the
"2005-08-11-06-mozilla1.8" and "2005-08-12-06-mozilla1.8" folders.  Are those
times indicate when the build was started or what time the nightly was available?

As for the impact, I first noticed this with the A9 toolbar.  Running the
toolbar under the Firefox 1.5 beta moves the drop down from the left to the
right in the search box.  I'm not sure if similar toolbars have the same issue.

Comment 12

[Mike Connor [:mconnor]]

This is fallout from a change we made around feedview, to allow sticking
arbitrary children in an hbox (RSS, security, others) in this position.  See
http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/autocomplete.xml#66
which basically makes any children <hbox> elements slot in there.

I'm not actually convinced that the change is something we want to revert and
work around in browser code, so unless there's wider impact on this from b1, I'd
rather poke A9 about their implementation (i.e. could they use a deck instead,
which should be backwards-compatible with 1.0).

Comment 13

[Colin Bleckner]

Hey Mike,

Thanks for the info.  As full disclosure: I work for A9, so consider the A9
people poked. :)  I changed the search box to use a stack* element instead of an
hbox and things seem to work correctly in Firefox 1.0 and the 1.5 beta.  I'm a
little concerned that I'm just arbitrarily using a stack, but everything seems
to display correctly so I guess I can't complain too much.

I'm not sure if this bug should be closed or not.  It looks like we've got a
work around for the A9 toolbar, but I don't know if this is impacting other people.


* I tried using a deck first, but that actually caused Firefox to crash.  The
XUL we're using is more complex than the test XUL file I attached, I imagine
we're doing something a little funky...

Comment 14

[Colin Bleckner]

Well Mike provided a work around for my problem and this seems to be an intended change, so I'm resolving (marking as WONTFIX).