This is a recent regression. Does not happen in 2005-02-20 7:13 am Firefox build. But it does happen with 2005-02-21 7:33am build. It happens on any file input button. So you can see this also in bugzilla when you try to attach something within bugzilla. You can see an example of the bug with the attachment in bug 249964. The "browse" button is almost not visible.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050220 Firefox/1.0+ Confirming regression from bug 252698 ?

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050220 Firefox/1.0+ build 15:43 PDT this is pre- bug 252698 checkin but I still see the problem so obviously that one isn't it.

Comment on attachment 175039 [details] test case input type="file"

input type="submit"

With the value="something" added the submit button is back to normal. 1. the default value (title) from the file button has gone awol. 2. the default buttonheigt for file and submit is gone,

CC-ing BZbarsky Can you have a look Boris ?

This looks like a regression from bug 279768, which moved dom/locales/en-US/chrome/layout/HtmlForm.properties which contains these strings...

To Gandalf. The patches in bug 279768 break this -- the location of HtmlForm.properties was changed, but references to it in the source were not (so anything in the source that uses HtmlForm.properties via nsContentUtils is broken). Gandalf, please do some testing when you move things around like this; actually trying to exercise the code that reads HtmlForm.properties would have caught this immediately.

Hmm... I did some testing, but not enough as we can see here. I even released fx for pl-PL users with those changes to test: http://beta.aviary.pl/firefox . A few people tested, nobody reported this issue. I'll fix it today. Sorry to all

patch.

Comment on attachment 175141 [details] [diff] [review] patch r+sr=bzbarsky

checked in

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050222 Firefox/1.0+ 10:20PST ->VERIFIED

*** Bug 283188 has been marked as a duplicate of this bug. ***

*** Bug 283294 has been marked as a duplicate of this bug. ***

This is being listed as VERIFIED FIXED on 2/22, but the official nightly builds, as of 2/24, still are broken. When will this patch be landed in the nightlies?

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050224 Firefox/1.0+ 13:44PST are you sure you haven't overwritten your program files/mozilla firefox/ directory. Just checked to make sure, this remains fixed for me

Yeah, this definitely isn't fixed in the nightlies, and I'm using Camino.

My dev build still shows the problem. My guess is that there's some stuff that needs to happen to get the strings into a place where embedders cna use them.

Camino only picks up embed.jar and pipnss.jar. Does it need more?

I'm guessing that the problem is that that embedding/config/embed-jar.mn was not updated to the new locations? For that matter, was it even picking up dom.properties before this change? It was probably picking up HtmlForm.properties via locale/XXXX/communicator/layout or something. Requesting blocking for anything resembling upcoming releases. Looks like the patches in bug 279768 need to be audited for their impact on embed.jar (in particular, we need to not package random unrelated crud in embed.jar).

This should really be a smoketest blocker. Camino builds are dead in the water with this bug (can't attach patches to bugzilla, for example).

*** Bug 283815 has been marked as a duplicate of this bug. ***

This patch adds global/dom, global/layout, and global/xslt to the embed-jar.mn. I also aligned all the lines in the file for readability. The patch is diff -uw.

Comment on attachment 175896 [details] [diff] [review] Patch to embed-jar.mn sr=bzbarsky. Here's hoping this gecko.jar thing happens soon so we don't need this anymore...

Comment on attachment 175896 [details] [diff] [review] Patch to embed-jar.mn r+ for me. Is this the only file I should check against future changes? I will be also moving caps.properties, security.properties and prettyprint.dtd

Checked in.

thanks for help Simon.

this might be a regression...HTML editor on www.blogger.com and also http://www.dynarch.com/demos/htmlarea/examples/core.html do not work, you can't type in the editor.

Nothing to do with this bug. It throws some exception in JS console in 1.0+ nightly.

See bug 284245 for that.