"Content" preferences pane is squished

RESOLVED FIXED in Firefox 2 beta2

Status

()

Firefox
Preferences
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

({fixed1.8.1, regression})

Trunk
Firefox 2 beta2
PowerPC
Mac OS X
fixed1.8.1, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [will be fixed by 347421])

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060801 Minefield/3.0a1

The "Content" preferences pane is squished.  If it's already the selected pane when I open preferences, it's cut off in addition to being squished.
(Reporter)

Comment 1

12 years ago
Created attachment 231570 [details]
screenshot
(Reporter)

Updated

12 years ago
Flags: blocking1.9a1?

Comment 2

12 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060731 Minefield/3.0a1

not squished on Windows. 
This is probably also a problem on the branch now that bug 345516 was checked in?
Yes, I can confirm I see this on today's branch Mac build - Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b1) Gecko/20060801 BonEcho/2.0b1, nominating.
Flags: blocking-firefox2?
Target Milestone: --- → Firefox 2 beta2
I'm not seeing this in my Mac builds, either on trunk or on branch.  Apparently other people are, which is rather odd.  I'm going to try to connect up offline with people like beltzner who are seeing this..
Target Milestone: Firefox 2 beta2 → ---
Target Milestone: --- → Firefox 2 beta2
Flags: blocking1.9a1?
Flags: blocking-firefox2?
Flags: blocking-firefox2+
Might it have something to do with the fact that the font names are bustificated as well? Try clicking on the default font combobox to see what I mean.

Comment 7

12 years ago
I'm seeing it as well with latest nightly and clean profile.  I'll come show you Jeff.
So...

As it turns out, looking at a busted Content pane using DOMi reveals some interesting extra elements not present in the Content pane.  These extra elements are placed there by the XForms extension, which apparently is part of official branch Mac nightlies for some unknown reason (see bug 347421), even tho it shouldn't be.  :-\  The XForms extension includes a prefwindow overlayd which attempts to overload a non-existent element with the id "contentGroupbox", causing general havoc in the window.

Essentially, this bug appears because the XForms extension hasn't been updated for the new prefwindow work and is incorrectly shipped with Mac builds.  Making it not build should fix the problem, so I'm making this bug depend on the bug to not ship XForms.
Depends on: 347421

Updated

12 years ago
Blocks: 347166

Comment 9

12 years ago
*** Bug 347522 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Whiteboard: [will be fixed by 347421]

Comment 10

12 years ago
Marking this fixed since it is fixed by the checkin to 34721
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
(Reporter)

Comment 11

12 years ago
Does this still happen if you install the XForms extension?  If so, a bug should probably be filed on it.

Comment 12

12 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2 ID:2006082101

It happens again, and XForms is installed again with this rc.

Comment 13

12 years ago
*** Bug 350777 has been marked as a duplicate of this bug. ***

Comment 14

11 years ago
In trunk build, It still reproduces. 
In 1.8brnach NB, there is no problem. 

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060922 Minefield/3.0a1

Comment 15

11 years ago
Hiro wrote:
> In 1.8branch NB, there is no problem.

That's not what I'm seeing - the latest branch builds (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20060922 BonEcho/2.0 with a brand new profile) still have the squished content preference tab and the default font can't be set.

Should this bug be reopened, then? It's marked as "will be fixed by 347421" but that bug is marked as fixed even though xforms is still part of the default build. 

Comment 16

11 years ago
Today, trunk build was normally displayed. 
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060929 Minefield/3.0a1

Comment 17

11 years ago
In Today trunk build, this problem has reproduced again...
What happens?

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061006 Minefield/3.0a1

Comment 18

11 years ago
"this problem", "it"... please file a new bug describing /exactly/ the bug you're seeing (be it the Xforms extension being installed, etc.)
You need to log in before you can comment on or make changes to this bug.