Closed Bug 283046 Opened 20 years ago Closed 20 years ago

File input button does not properly render (in embedding apps)

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set
blocker

Tracking

()

RESOLVED FIXED
mozilla1.8beta2

People

(Reporter: martijn.martijn, Assigned: zbraniecki)

References

Details

(Keywords: regression, testcase)

Attachments

(6 files)

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 ?
Attached file test case
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... 
Blocks: 279768
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.
Assignee: nobody → gandalf
No longer blocks: 279768
OS: Windows XP → All
Hardware: PC → All
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 
Status: NEW → ASSIGNED
Attached patch patchSplinter Review
patch.
Attachment #175141 - Flags: review?(bzbarsky)
Comment on attachment 175141 [details] [diff] [review]
patch

r+sr=bzbarsky
Attachment #175141 - Flags: superreview+
Attachment #175141 - Flags: review?(bzbarsky)
Attachment #175141 - Flags: review+
checked in
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050222
Firefox/1.0+ 10:20PST

->VERIFIED
Status: RESOLVED → 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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Summary: File input button does not properly render → File input button does not properly render (in embedding apps)
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).
Flags: blocking-aviary1.1?
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.
Attachment #175896 - Flags: superreview?(bzbarsky)
Attachment #175896 - Flags: review?(gandalf)
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...
Attachment #175896 - Flags: superreview?(bzbarsky) → superreview+
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
Attachment #175896 - Flags: review?(gandalf) → review+
Checked in.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
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.
Flags: blocking-aviary1.1?
Target Milestone: --- → mozilla1.8beta2
Blocks: 279768
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: