Closed Bug 113295 Opened 24 years ago Closed 24 years ago

Quit, Close, Redo text is invisible on Mac.

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.7

People

(Reporter: bzbarsky, Assigned: bugs)

References

Details

(Keywords: access, regression, smoketest)

Attachments

(1 file, 1 obsolete file)

Change to mac build scripts to ensure that mac locale is registered last
1.44 KB, patch
paulkchen
: review+
Details | Diff | Splinter Review
The Quit, Close, Redo menuitems have disappeared. The Ctrl-q and Ctrl-w shortcuts have stopped working. This makes the browser kinda hard to use...
Keywords: access, mozilla0.9.7, regression
I see this on win2k also. Hoping the same on mac too ;-)
OS: Linux → All
Hardware: PC → All
On the Mac OS 9 build most of the menu items in both the File and Edit menus show up as "Blank Menu Item". You can not Quit the application because of this. IMO This should be a blocker...
My inclination is to agree with the blocker status, so adding, since the tree might open pretty soon if we don't. We can always remove it...
Severity: major → blocker
Keywords: smoketest
*** Bug 113268 has been marked as a duplicate of this bug. ***
OK. Confirmed that this is caused by Ben's overlay stuff. Pulling by date for 00:06 has the menus working fine, pulling for 01:15 has them broken.
Where was platformCommunicatorOverlay.dtd added to the jar?
Er, more accurately -- where was the new jar.mn added to the build system?
this is much worse on Mac os9. nearly all Menu items under File and Edit are listed as "Blank menu item."
A couple of LXR searches seem to imply that the .dtd file was not added to: /xpfe/communicator/resources/content/mac/platformCommunicatorOverlay.xul even though one exists in /xpfe/communicator/resources/locale/en-US/mac/ And that, though /xpfe/communicator/resources/content/os2/platformCommunicatorOverlay.xul references a dtd file, one does not exist in /xpfe/communicator/resources/locale/en-US/os2/
Also, browserBindings.xml still includes the old platformGlobalOverlay. I think there are enough problems here that we should probably back Ben out and let him fix them at his leisure. Any other opinions?
This makes linux work fine, but should be tested on other platforms (esp. to make sure it builds correctly). It _looks_ like this should make things work, though.
I think you want to leave the + in the jar.mn. Why do we need separate OS/2 files? Can't they just use Windows or Unix ones? Should the DIRS line in Makefile.in be properly ifdef-ed like in xpfe/global/resources/content/Makefile.in ?
looking...
Status: NEW → ASSIGNED
And also, do you need some of the other junk in the makefiles so that non-JAR builds work?
Comment on attachment 60207 [details] [diff] [review] Patch to fix all the problems found so far OK. The patch was mostly meant as a demo of what's up: 1) No makefiles in the new platform dirs in xpfe/communicator/resources/locale/en-US 2) Need to add the new dirs to the makefile in xpfe/communicator/resources/locale/en-US 3) jar filenames wrong in jar.mn in all the new dirs 4) Missing DTD on os2. 5) Need to add os2 dir in makefiles in xpfe/global/resources/locale/en-US
Attachment #60207 - Attachment is obsolete: true
6) "Also, browserBindings.xml still includes the old platformGlobalOverlay." as David says.
I looks like part of the problem on the Mac is a typo.. xpfe/communicator/resources/content/mac/platformCommunicatorOverlay.xul#4 should read: <!DOCTYPE window SYSTEM "chrome://communicator-platform/locale/platformCommunicatorOverlay.dtd"> not: <!DOCTYPE window SYSTEM "chrome://communicator-platform/locale/platformCommunicatorOverlay.xul">
*** Bug 113326 has been marked as a duplicate of this bug. ***
Reducing severity to get tree open, we are close to a fix.
Severity: blocker → critical
*** Bug 113363 has been marked as a duplicate of this bug. ***
resummarizing to reflect the state of the world.
Priority: -- → P1
Hardware: All → Macintosh
Summary: No Quit, Close, Redo menuitems or ctrl-q, ctrl-w shortcuts → Quit, Close, Redo text is invisible on Mac.
Target Milestone: --- → mozilla0.9.7
*** Bug 113443 has been marked as a duplicate of this bug. ***
I am no longer seeing blank menu items on mac commercial build 2001-12-04-04-trunk
*** Bug 113432 has been marked as a duplicate of this bug. ***
One of the dupes mentions Appearance > Fonts > Size being blank. Just want to make sure the fix resolves that as well.
*** Bug 113478 has been marked as a duplicate of this bug. ***
Latest dup here reported on Linux w/build 2001120408 Dean Tessman: font size dropdown maybe bug 112907
I see that ben checked some stuff in for this, but it is no better in my pull from this morning. Is this supposed to be fixed? I still have no menu items on mac OS 9.
This is blocking my work; I am upgrading the severity to blocker.
Severity: critical → blocker
does that mean the tree will be closed? I see it is already oprn today.
Yeah looks like this is fixed now.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
this was on all platforms....why did the summary and paltform get changed to mac? the behavior on mac was different than the other platforms (ie blank menu item compared to "invisible" menu item on today's builds it is fixed on mac and linux but still present on windows (ie File | Quit is invisible...it works if you click it, there just isn't any text present) reopening and down grading to critical; 'cause even though it is not expected of a normal user to know what the menu item is, for testing/development, it is not blocking work. windows 2001-12-04-10-trunk (still present) linux 2001-12-04-08-trunk (okay) mac 2001-12-04-04-trunk (okay) mac osx 2001-12-08-trunk (okay)
Severity: blocker → critical
Status: RESOLVED → REOPENED
Keywords: smoketest
Resolution: FIXED → ---
Summary: Quit, Close, Redo text is invisible on Mac. → Quit, Close, Redo text is invisible
aligning platform to what this currently affecting
OS: All → Windows 98
Hardware: Macintosh → PC
Tracy, which Mac platform? On OS 9 I'm still seeing nothing but lists of "Blank Menu Item". Is this just my build?
what is the fix for this bug? I am stuck!!! I am stuck with my Mac build so changing platforms back to ALL/ALL.
Status: REOPENED → ASSIGNED
Keywords: smoketest
OS: Windows 98 → All
Hardware: PC → All
Summary: Quit, Close, Redo text is invisible → Quit, Close, Redo text is invisible on Mac.
Brian...my OS9 worked fine in smoketests today.
*** Bug 113493 has been marked as a duplicate of this bug. ***
I am using commercial....You guys on Mozilla?
Sorry, should have mentioned that. Yes mozilla development build.
ah...in that case, for mozilla, this is a blocker. sorry 'bout the confusion. putting it back to such
Severity: critical → blocker
We found out why this happens. These lines in the mac build scripts: CreateJarFromManifest(":mozilla:xpfe:components:prefwindow:resources:content:mac: jar.mn", $chrome_dir, \%jars); CreateJarFromManifest(":mozilla:xpfe:components:prefwindow:resources:locale:en- US:unix:jar.mn", $chrome_dir, \%jars); CreateJarFromManifest(":mozilla:xpfe:components:prefwindow:resources:locale:en- US:win:jar.mn", $chrome_dir, \%jars); cause the unix and windows communicator/platform jars to be registered before those for Mac, so we end up with chrome for the wrong platform. Why again do we need unix and windows chrome on Mac? Tao? Release builds work because the installer generates installed-chrome.txt.
Severity: blocker → critical
OS: All → Mac System 9.x
Hardware: All → Macintosh
We have a fix.
Severity: critical → blocker
Comment on attachment 60380 [details] [diff] [review] Change to mac build scripts to ensure that mac locale is registered last r=pchen
Attachment #60380 - Flags: review+
Comment on attachment 60380 [details] [diff] [review] Change to mac build scripts to ensure that mac locale is registered last r=bryner
>cause the unix and windows communicator/platform jars to be registered before >those for Mac, so we end up with chrome for the wrong platform. Why again do we >need unix and windows chrome on Mac? Tao? This problem can be fixed by "selecting" en-mac.jar as the platform provider on Mac. Does registerChrome work on Mac? If so, you explicitly select which provider via registerChrome. This way, you don't rely on the build sequence to determine the chrome providers.
simon checked in a patch.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
tao: can you provide a mac build script patch that does this?
*** Bug 113612 has been marked as a duplicate of this bug. ***
Still missing one in Mail in the View > Sort menu. Close, Exit, and Redo are back. 2001120504 on Windows
vrfy fixed on mac 10.1.1 and 9.1 [emul over X] using 2001.12.05.0x-comm bits.
Status: RESOLVED → VERIFIED
Er. Verified on Windows and Linux? (A lot of the duplicates are manifestations on Windows/Linux.)
d'oh, right: yep, Quit, Close and Redo are [back] in the menus on winNT and linux rh7.2 [tested w/2001.12.05-comm bits].
Does "FIXED" state imply the fixes are checked into the trunk and included in subsequent trunk nightly builds? If so, there is still a problem on Linux. Build 2001120608 has blank labels in the File menu of the *original* mozilla window (not subsequently opened browser windows). Also Preferences->Security has 4 blank lables in the menu tree on the side.
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: