Closed
Bug 113295
Opened 23 years ago
Closed 23 years ago
Quit, Close, Redo text is invisible on Mac.
Categories
(SeaMonkey :: UI Design, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.7
People
(Reporter: bzbarsky, Assigned: bugs)
References
Details
(Keywords: access, regression, smoketest)
Attachments
(1 file, 1 obsolete file)
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...
![]() |
Reporter | |
Updated•23 years ago
|
I see this on win2k also. Hoping the same on mac too ;-)
OS: Linux → All
Hardware: PC → All
Comment 2•23 years ago
|
||
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. ***
![]() |
Reporter | |
Comment 5•23 years ago
|
||
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?
Comment 8•23 years ago
|
||
this is much worse on Mac os9. nearly all Menu items under File and Edit are listed as "Blank menu item."
Comment 9•23 years ago
|
||
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?
![]() |
Reporter | |
Comment 11•23 years ago
|
||
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 ?
And also, do you need some of the other junk in the makefiles so that non-JAR builds work?
![]() |
Reporter | |
Comment 15•23 years ago
|
||
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
![]() |
Reporter | |
Comment 16•23 years ago
|
||
6) "Also, browserBindings.xml still includes the old platformGlobalOverlay." as David says.
Comment 17•23 years ago
|
||
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">
Comment 18•23 years ago
|
||
*** Bug 113326 has been marked as a duplicate of this bug. ***
Comment 19•23 years ago
|
||
Reducing severity to get tree open, we are close to a fix.
Severity: blocker → critical
Comment 20•23 years ago
|
||
*** Bug 113363 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 21•23 years ago
|
||
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
Comment 22•23 years ago
|
||
*** Bug 113443 has been marked as a duplicate of this bug. ***
Comment 23•23 years ago
|
||
I am no longer seeing blank menu items on mac commercial build 2001-12-04-04-trunk
![]() |
Reporter | |
Comment 24•23 years ago
|
||
*** Bug 113432 has been marked as a duplicate of this bug. ***
Comment 25•23 years ago
|
||
One of the dupes mentions Appearance > Fonts > Size being blank. Just want to make sure the fix resolves that as well.
Comment 26•23 years ago
|
||
*** Bug 113478 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
Latest dup here reported on Linux w/build 2001120408 Dean Tessman: font size dropdown maybe bug 112907
Comment 28•23 years ago
|
||
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.
Comment 29•23 years ago
|
||
This is blocking my work; I am upgrading the severity to blocker.
Severity: critical → blocker
Comment 30•23 years ago
|
||
does that mean the tree will be closed? I see it is already oprn today.
Assignee | ||
Comment 31•23 years ago
|
||
Yeah looks like this is fixed now.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 32•23 years ago
|
||
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
Comment 33•23 years ago
|
||
aligning platform to what this currently affecting
OS: All → Windows 98
Hardware: Macintosh → PC
Comment 34•23 years ago
|
||
Tracy, which Mac platform? On OS 9 I'm still seeing nothing but lists of "Blank Menu Item". Is this just my build?
Comment 35•23 years ago
|
||
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.
Comment 36•23 years ago
|
||
Brian...my OS9 worked fine in smoketests today.
![]() |
Reporter | |
Comment 37•23 years ago
|
||
*** Bug 113493 has been marked as a duplicate of this bug. ***
Comment 38•23 years ago
|
||
I am using commercial....You guys on Mozilla?
Comment 39•23 years ago
|
||
Sorry, should have mentioned that. Yes mozilla development build.
Comment 40•23 years ago
|
||
ah...in that case, for mozilla, this is a blocker. sorry 'bout the confusion. putting it back to such
Severity: critical → blocker
Comment 41•23 years ago
|
||
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
Comment 43•23 years ago
|
||
Comment 44•23 years ago
|
||
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 45•23 years ago
|
||
Comment on attachment 60380 [details] [diff] [review] Change to mac build scripts to ensure that mac locale is registered last r=bryner
Comment 46•23 years ago
|
||
>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.
Assignee | ||
Comment 47•23 years ago
|
||
simon checked in a patch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 48•23 years ago
|
||
tao: can you provide a mac build script patch that does this?
Comment 49•23 years ago
|
||
*** Bug 113612 has been marked as a duplicate of this bug. ***
Comment 50•23 years ago
|
||
Still missing one in Mail in the View > Sort menu. Close, Exit, and Redo are back. 2001120504 on Windows
Comment 51•23 years ago
|
||
vrfy fixed on mac 10.1.1 and 9.1 [emul over X] using 2001.12.05.0x-comm bits.
Status: RESOLVED → VERIFIED
Comment 52•23 years ago
|
||
Er. Verified on Windows and Linux? (A lot of the duplicates are manifestations on Windows/Linux.)
Comment 53•23 years ago
|
||
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].
Comment 54•23 years ago
|
||
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.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•