Closed
Bug 315889
Opened 19 years ago
Closed 19 years ago
Flash 7/8-Based Application Does Not Reposition On-Screen When Using "Hide Toolbar" Option
Categories
(Camino Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: mpeaston, Assigned: mikepinkerton)
References
Details
Attachments
(8 files)
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Camino/1.0b1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Camino/1.0b1
My organisation uses a Macromedia Flash 7-based application that has been designed to operate best in a 1024*768 resolution screen. When viewing the application in Camino 1.01b I attempted to "fit" the application better on-screen by selecting the "Hide Toolbar" option to provide the application with more screen space and to avoid having to scroll the screen. However, when doing this the Flash canvas stays in the same position but now with an empty white space above it. Additionally, the vertical scrollbar disappears and the canvas "hangs over" the edge of the Camino window. It seems that Flash 7 (and Flash 8) doesn't reposition the canvas on-screen when the "Hide Toolbar" option is selected in order to make use of the avaialable screen real estate.
Screenshots will be posted to assist since this application is not accessible outside of my organisation.
Reproducible: Always
Steps to Reproduce:
1. Open Flash-based application in Camino
2. Select "Hide Toolbar" option from the View menu.
Actual Results:
Flash application canvas remains in the same place on-screen rather than moving up the screen to fill the space now made available by removing the toolbar. Vertical scrollbars disappear and the application canvas appears to hang over the edge of the Camino window.
Expected Results:
Flash application canvas should reposition itself to the top of the available browser window. Canvas should also not appear over the status bar at the base of the Camino window.
Reporter | ||
Comment 1•19 years ago
|
||
Reporter | ||
Comment 2•19 years ago
|
||
Note that the application canvas has not moved when compared to the screenshot in attachment #202523 [details] and that the base of the application canvas now covers the Status bar at the base of the Camino window.
Updated•19 years ago
|
Summary: Flash 7-Based Application Does Not Reposition On-Screen When Using "Hide Toolbar" Option → Flash 7/8-Based Application Does Not Reposition On-Screen When Using "Hide Toolbar" Option
Assignee | ||
Comment 3•19 years ago
|
||
can we get a url so we can try to reproduce this? does it only happen with your flash object, or all of them?
Here's an anti-testcase. I declared a Flash object with size 1024x768 in this page. When I click the "Hide Toolbar" widget, the size of my entire Camino window (content + chrome) shrinks by the height of the toobar. The BM Bar, Tab Bar, content area [including Flash] and Status Bar all move upwards, together, by the height of the toolbar.
WFM Camino 2005111004 (v1.0b1+) based on that, so a real testcase that causes the bug for you would be helpful.
Reporter | ||
Comment 5•19 years ago
|
||
Unfortunately the application for which I provided screenshots is a proprietory application that is only accessible within my organisation's network so I am unable to provide a URL for it. I raise this bug because I know that there is a problem with the way that Camino handles this particular application and I assume that the same problem will happen with other such applications. In order to test this theory I have created a simple Flash movie with a canvas sized at 1024*768 with a rectangular border and some text. When a web page containing the movie is opened in Camino it correctly positions it and adds the necessary horizontal and verticle scrollbars. However, when the "Hide Toolbar" option is selected the canvas is not repositioned on-screen and it appears to "hang" over the status bar.
However, I note now that this condition only appears when Camino is maximised on the screen. If the application window is sized less than that allowed by the screen then the behaviour is correct. Additionally, when the "incorrect" condition is created (as outlined above) and the application window is manually resized then the Flash canvas correctly repositions itself.
The test canvase that I created can be accessed at the following URL: http://homepage.mac.com/mpeaston/testcanvas.html
Sorry for the delay in uploading the test but my regular website seems to be on the fritz at the moment...
Reporter | ||
Comment 6•19 years ago
|
||
Reporter | ||
Comment 7•19 years ago
|
||
Please note that this problem only seems to occur if the application window is maximised to begin with and fills the complete height of the screen.
Reporter | ||
Comment 8•19 years ago
|
||
Screenshot shows that the Flash canvas is correctly repositioned when the Toolbar is removed relative to the top of the screen, but it still covers the Status bar at the base of the window.
Reporter | ||
Comment 9•19 years ago
|
||
The anti-testcase is interesting. When I view the page as normal (with Camino maximised on-screen) and then select "Hide Toolbar" the anti-testcase is correctly repositioned relative to the top of the screen (i.e. it moves up to fill the void left by the hidden toolbar). However, it does cover the Status Bar of the application in the same way my test case does. Still, odd that it does "move" when the Toolbar is hidden. I wonder what the difference between the 2 test cases are...
This is still WFM, even when my Camino window takes up the entire screen. So I'm guessing this is 10.4-only? Samuel, Wevah, can you reproduce?
I still don't understand why the status bar isn't moving upward for Marcus when he collapses the toolbar (i.e., the window remains maximized to the screen, whereas the for me shrinks by the amount of the toolbar). Does 10.4/unified toolbar change window resizing behavior?
Comment 11•19 years ago
|
||
I can't trigger on 10.4.3 with either the anti-testcase or the testcase listed in comment 5.
Marcus, is there anything "different" about your setup? Can you try using a new profile and see if this bug still occurs? (Removing [or renaming if you don't want to lose your settings] ~/Library/Application Support/Camino and relaunching Camino will give you a new profile.)
Likewise, if you can move org.mozilla.camino.plist from your ~/Library/Preferences folder before testing, that will help as well. Don't delete it (and you can move it back afterwards). That's the file that contains window settings and such. If that's what's causing the problem, I'd like to see it.
Reporter | ||
Comment 12•19 years ago
|
||
OK, I tried both removing ~/Library/Application Support/Camino and ~/Library/Preferences/org.mozilla.camino.plist but the result is still the same. The only thing that I can think of at this time is that I installed the Iridium 1.6.6 theme a while ago and, since that changes the look of OS X 10.4.3, perhaps that has something to do with it. At the moment I'm trying to work out how to remove it and get the "default" Tiger theme back again but I'm not sure if this is possible without reinstalling Tiger. In the meantime the glitch still seems to occur.
Reporter | ||
Comment 13•19 years ago
|
||
Just as a follow-up, and I hope you guys appreciate this, but I completely scrubbed my PowerBook, reinstalled OS X 10.4.3 and Camino 1.0b1, and I still get the same problem. Mostly I did this because my attempts to remove Iridium were somewhat less than successful but still...
Screenshots of the test with a virginal Camino and OS X 10.4.3 to be attached in just a moment.
Reporter | ||
Comment 14•19 years ago
|
||
Reporter | ||
Comment 15•19 years ago
|
||
Again, in this screenshot please note that the Flash canvas does not reposition itself and crosses into the status bar.
Blocks: 225397
Comment 16•19 years ago
|
||
I still can't reproduce this.
Marcus, is this something you still see with Camino 1.0?
Reporter | ||
Comment 17•19 years ago
|
||
(In reply to comment #16)
> I still can't reproduce this.
>
> Marcus, is this something you still see with Camino 1.0?
>
Hi Samuel,
Actually, I'd completely forgotten about this bug since it's been a while since we have visited it. However, in answer to your question, Camino 1.0 does indeed appear to resolve the problem when checked against my test case. I haven't checked it against the Flash-based application at work that prompted the Bug in the first place so I'll give that a bash tomorrow and see if everything is OK there as well.
Regards,
Marcus
Comment 18•19 years ago
|
||
Marcus, thanks for getting back to us and please let us know as soon as you do. :)
Reporter | ||
Comment 19•19 years ago
|
||
OK, I've tested Camino 1.0 at work against the Flash application that first highlighted a problem and I can confirm that the problem no longer occurs. Hurrah!
Whatever was changed in v1.0 it seems to have nuked this bug so I'm setting the status of this Bug as FIXED.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 20•19 years ago
|
||
Since we're not sure what checkin fixed this, reopening to resolve as WFM.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Updated•19 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•