Closed Bug 275000 Opened 20 years ago Closed 20 years ago

Some inputs are missing default values resulting in small-sized buttons (with no text)

Categories

(Firefox :: Installer, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: nirvn.asia, Assigned: steffen.wilberg)

References

()

Details

(Keywords: regression, testcase)

Attachments

(3 files, 1 obsolete file)

With input type submit, reset and file, the default value="" is missing
resulting in tiny buttons of approx. 2px height per 6px width.

I get this problem with the firefox build Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.8a6) Gecko/20041216 Firefox/1.0+

I can also confirm it is _not_ doing this with the mozilla suite 1.8a5 so I
guess it's a core change that after 1.8a6 and now ...
Attached file collection of problematic input types (obsolete) —
A small table showing boggus inputs with custom value="" field (resulting in a
nice shaped button) and without the value="" filed
WFM: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6)
Gecko/20041216 Firefox/1.0+
The buttons on the right column are labelled "Submit Query", "Reset" and
"Browse...". 

Also, notice that your INPUT tags are missing their closing ">"s. Not sure if
that's significant or not.
Component: Form Manager → Layout: Form Controls
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a6) Gecko/20041216 Firefox/1.0+
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a6) Gecko/20041215

Firefox version as seen using Windows Explorer right-click Properties: 
1.8a6: 2004121606
well the only thing that comes into my mind is the fact that I installed this
new version over ff1.0final, I'll try with a fresh install.

strangeuh
I'm confirming this, because I can see it in the 20041215 FF trunk installer.

It does not occur in the 20041215 FF zip build or the 20041215 Seamonkey build.

Cleaned up testcase forthcoming.  This is not an issue with malformed input tags
as suggested previously.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, testcase
Version: Trunk → Other Branch
Attached image screenshot
Attached file testcase
Note that even the input file button on the attachment creation form also shows
this bug.
Attachment #168922 - Attachment is obsolete: true
*** Bug 275146 has been marked as a duplicate of this bug. ***
*** Bug 275225 has been marked as a duplicate of this bug. ***
That's kinda misleading to have this bug in Core, when it's not a core bug
(works in seamonkey), with version set to "Other branch", when we're talking
about trunk builds. Also, the summary doesn't make this bug easy to find. And
should this have an aviary-landing on it?
(In reply to comment #10)
> That's kinda misleading to have this bug in Core, when it's not a core bug
> (works in seamonkey), with version set to "Other branch", when we're talking
> about trunk builds. Also, the summary doesn't make this bug easy to find. And
> should this have an aviary-landing on it?

I didn't write the summary, feel free to contribute a better one.

I'm not clear whether Core/Layout or FF/Installer is better, so I left it where
it was filed.

Yes, it's a landing bug.
Keywords: aviary-landing
ok, my variant is not the best possible, but it includes a few keyword I would
search for. Also, I'm taking liberty of moving this bug to Firefox. (I have this
problem with an installer build, does it work with zip builds?)
Severity: normal → major
Component: Layout: Form Controls → Installer
Product: Core → Firefox
Summary: Some inputs are missing default values resulting in tiny buttons → Some inputs are missing default values resulting in small-sized buttons (with no text)
Version: Other Branch → Trunk
Well, you didn't come close to moving it to the right component.

This is an installer only bug.
Assignee: dveditz → bugs
Severity: major → normal
QA Contact: bugzilla
This bug is similar to the issue previously fixed in bug 272982.  Replacing the
installer version application chrome installed-chrome.txt file with one form a
zip build and removing the application chrome.rdf file so that it will get
recreated results in a working (as far as this issue is concerned at least )
installer build.
We need to register chrome://communicator/locale/ for files like
chrome://communicator/locale/layout/HtmlForm.properties and
chrome://communicator/locale/dom/dom.properties.

I also changed "en-US" (which I introduced in bug 272982) to the proper
"@AB_CD@".
Assignee: bugs → steffen.wilberg
Status: NEW → ASSIGNED
Attachment #169308 - Flags: review?(bsmedberg)
OS: Windows XP → All
Forgot to mention that this patch is restoring this change to the former
langenus.jst:
http://bonsai.mozilla.org/cvsquery.cgi?branch=&date=explicit&mindate=2004-07-16+12%3A57&maxdate=2004-07-16+12%3A57
Comment on attachment 169308 [details] [diff] [review]
register chrome://communicator/locale/ again

Yeah, the communicator package has got to disappear again, but I haven't
finished that yet.
Attachment #169308 - Flags: review?(bsmedberg) → review+
Checking in mozilla/browser/installer/unix/ab-CD.jst;
/cvsroot/mozilla/browser/installer/unix/ab-CD.jst,v  <--  ab-CD.jst
new revision: 1.4; previous revision: 1.3
done
Checking in mozilla/browser/installer/windows/ab-CD.jst;
/cvsroot/mozilla/browser/installer/windows/ab-CD.jst,v  <--  ab-CD.jst
new revision: 1.4; previous revision: 1.3
done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: aviary-landing
Resolution: --- → FIXED
V fixed 20041222 PC/WinXP
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → installer
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: