363159 - Password box remains blank even if I enter a password - gcc 4.1 related bug ?

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Frederic Bezies]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061208 Firefox/3.0a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061208 Firefox/3.0a1

Very weird display bug. I do not see it in gran paradiso alpha1 release.

Go to a page which needs login + password. Enter both. On my homemade builds, password box remains blank, but not on mozilla.org nightlies.

Reproducible: Always

Steps to Reproduce:
1. Go for example to this page http://frederic.bezies.free.fr/forum/login.php
2. Enter "blabla" in left box, "bloblo" in the right one (without quotes)


Actual Results:  
Only username box is filled.

Expected Results:  
Boths boxes filled with characters / * for password box.

Using a mozconfig copied from the official one :

#
# See http://www.mozilla.org/build/ for build instructions.
#

. $topsrcdir/browser/config/mozconfig

# Options for 'configure' (same as command-line options).
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --disable-tests

ac_add_options --enable-canvas
ac_add_options --enable-svg
ac_add_options --enable-pango
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --enable-static
ac_add_options --disable-shared

Using gcc 4.1.1 from Ubuntu 6.10, Gnome 2.16. No error in error console.

Sorry if this bug is already known.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I can't reproduce this; I'm guessing it could be some oddness with cairo maybe, or some specific version of pango/etc.  If it's still a problem, we'd need more details.

Comment 2

[Frederic Bezies]

More details, because if it is invalid, I'm color blind !

I'm using trunk code, the same .mozconfig, the same versions of gcc, ubuntu, gnome.

Pango ? 1.14.5
Cairo ? 1.2.4

Both old and newly made profile show this bug. And also, when using firefox 2 bundled with Ubuntu 6.10, no display problem.

Here is the about:buildconfig options of ubuntu's firefox :

-host=i486-linux-gnu --build=i486-linux-gnu --prefix=/usr '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' --enable-default-toolkit=gtk2 --with-default-mozilla-five-home=/usr/lib/firefox --enable-pango --with-user-appdir=.mozilla --with-system-png=/usr --with-system-jpeg=/usr --disable-mailnews --disable-composer --disable-ldap --enable-postscript --disable-installer --disable-xprint --enable-crypto --disable-strip --disable-strip-libs --enable-canvas --enable-svg --enable-svg-renderer=cairo --enable-system-cairo --enable-mathml --disable-tests --disable-gtktest --disable-debug --enable-xft '--enable-optimize=-pipe\ -w\ -O2\ -g\ -fno-strict-aliasing' --with-system-zlib=/usr --without-system-nspr --enable-xinerama --enable-extensions=default --disable-pedantic --disable-long-long-warning --enable-single-profile --disable-profilesharing --enable-gnomevfs --enable-application=browser --disable-installer --disable-updater --enable-chrome-format=flat --disable-elf-dynstr-gc --enable-system-myspell --with-distribution-id=com.ubuntu

Maybe using system-cairo could cure this bug ? Anyway, I'm still seeing it. So, it could be my sight the problem :(

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Cairo 1.2.4 is old, but if you're not building with --enable-system-cairo, then it shouldn't matter.  Using system cairo most likely won't even build right now, so that won't fix much of anything.  The bug is still invalid though, because you can't reproduce it with the real nightly builds.

Comment 4

[Frederic Bezies]

When I try to reproduce with an official nightly, firefox doesn't work, just eating up memory.

At least with official nightlies from 28 and 29 january :(

Comment 5

[Frederic Bezies]

When I launch an official nightly from terminal, after saying "yes" to set firefox as default browser, I got this message :

(Gecko:7489): libgnomevfs-WARNING **: Fonction obsolète. Les modifications d'utilisateur sur la base MIME ne sont plus supportées.

Translated into english :

(Gecko:7489): libgnomevfs-WARNING **: Obsolete fonction. Users modification on MIME base are not supported anymore.

After that, when I click on an url I add in my personal toolbar or if I enter an url in the address bar, when it comes to loading, nothing happens but firefox going crazy and eating up to 875 Mb of ram :(

The strange part is that builds options I am using are the same, but not for update tool and optimization line :(

/me is lost !

Comment 6

[Frederic Bezies]

I noticed that nightlies are built using gcc 3.2.3. But I'm using gcc 4.1.1.

So, the bug I'm facing and which you closed as invalid (even if I disagree !) could it be related to gcc version used ?!

Just guessing, of course

Comment 7

[Frederic Bezies]

I have a debug log.

I built firefox with source up-to-date at :

checkout finish: lundi 19 février 2007, 17:49:40 (UTC+0100)

With this .mozconfig :

#
# See http://www.mozilla.org/build/ for build instructions.
#

. $topsrcdir/browser/config/mozconfig

# Options for 'configure' (same as command-line options).
ac_add_options --enable-debug

ac_add_options --enable-canvas
ac_add_options --enable-svg
ac_add_options --enable-pango
ac_add_options --enable-default-toolkit=cairo-gtk2

I reproduce comment #0 steps.

I will attach the log, but a lot of lines seems to be related to gnuTLS or something like this.

Hope it could help ?!

Comment 8

[Frederic Bezies]

Attachment: debug log created with ./firefox >& debug.log &

Debug log. Maybe the answer to this INVALID bug is here ?!

Comment 9

[Frederic Bezies]

Attachment: right log this time :(

Comment 10

[Frederic Bezies]

close it as invalid.

No answer for 9 days, even after giving a debug log :(

My linux distro should be guilty there, I suppose.

Comment 11

[David Edwards]

Can this be re-opened? I believe it is a real bug.

I found this behaviour in the nightlies from Mozilla for some weeks during February and March, on some password fields but not all. One that always didn't work was www.hotmail.com. I thought it was M$oft's fault and reported it as a broken web-site.

As of today (build 20070331 (and also 20070329)) it does work, but what appears in the hotmail password field is

●●●●●●

Surely this isn't what is supposed to happen?

Comment 12

[David Edwards]

Aargh! In the e-Mail confirming my comment, the things above, which in my browser on my machine are a little box with two lines in it

25 on top line
CF on bottom line

actually appear as blobs, which is what I would expect. Is this some font funny?

Comment 13

[Simon Montagu :smontagu]

That should be filed as a new bug rather than reopening this one. 25CF is the Unicode value for the black blob, so what is happening is that we aren't finding a font for the character and you are seeing a missing glyph indicator.

Comment 14

[David Edwards]

Should I do that?