Closed Bug 402648 Opened 13 years ago Closed 13 years ago

Page layout on X11 platforms incorrectly overlays applets

Categories

(Core :: Layout, defect, P2)

x86
Linux
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: kbrussel, Assigned: kinetik)

References

()

Details

(Keywords: regression)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9a9pre) Gecko/2007110502 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9a9pre) Gecko/2007110502 Minefield/3.0a9pre

On X11 platforms only, we are seeing parts of the page incorrectly
overlay a Java applet with the current Firefox 3 build. The same page
renders correctly on the Windows platform with the current Firefox 3
build.

The application (http://swinglabs.org/iris/) is a mixed Java applet
and HTML photo editor and viewer. The initial view which shows a
user's albums and the photos in an album is all HTML aside from the
"toolbox" applet across the bottom of the page. When the photo editor
or slide show view is opened, CSS and z-ordering tricks are done to
"veil" the HTML portion of the web page and the photo editor applet
and some surrounding HTML elements are overlaid on top of the original
HTML display.

The editor applet is supposed to overlay all of the HTML elements.
Because it is a true OS-level window, it does so, at least on the
Windows platform. On X11 platforms it appears that the browser is
creating sub-windows to represent different regions of the page's
rendering results, which causes the applet to be incorrectly clipped.

The attached screen shots show the correct rendering results with
Firefox 2 (on Solaris/x86) and the incorrect rendering results with
Firefox 3 (on Linux). The behavior on these platforms is identical; FF
2 renders the page correctly and FF 3 does not.


Reproducible: Always

Steps to Reproduce:
1. Download the latest Java SE 6 runtime environment (JRE) for an X11
platform (Linux, Solaris) from
http://java.sun.com/javase/downloads/index.jsp . I recommend using the
self-extracting installer for Linux as opposed to the RPM. Extract it.

2. Create a symlink in the firefox/plugins directory (of either FF 2
or FF 3) to .../plugin/i386/ns7/libjavaplugin_oji.so .

3. Navigate to http://swinglabs.org/iris/ .

4. Once the page loads, enter a Flickr account name (for example
"kenneth russell"). (If you have difficulty getting the albums for a
user to load, please contact me via email -- you are likely
encountering 6595618, which has been fixed in a not-yet-released Java
6 update.)

5. Select an album in the left pane. Double-click a particular photo
in the right pane to open the editor.

With FF 2 the editor will open correctly. With FF 3 the editor will be
clipped by the web page.

Note that we have tried tweaking the z-order of the applet to no effect.
Actual Results:  
Applet is incorrectly clipped by the surrounding web page.

Expected Results:  
Applet displays correctly, without interference from other page elements.
Roc, any ideas on what could be causing this?
Component: General → Layout
Keywords: regression
Product: Firefox → Core
QA Contact: general → layout
Flags: blocking1.9?
nope, but Karl may have an idea
No ideas here.  I can reproduce.  Probably worth getting a regression range.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #5)
> Probably worth getting a regression range.

But that could be difficult.  I get "Applet not inited" with alpha6, and versions from 2007-07-03 to 2007-09-29 will crash. 

(In reply to comment #6)
> I get "Applet not inited" with alpha6.

OK, that was the wrong java version.

Same problem reproducible in alpha6.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P4
Regression range is needed here.
Has there been any progress on tracking down the root cause of this bug?
(In reply to comment #9)
> Has there been any progress on tracking down the root cause of this bug?

It's due to something that happened before alpha6.
Comparing earlier alphas to get a regression range may be helpful.
Karl - any chance you can take this - looks to be a showstopper on the sun side..
Assignee: nobody → mozbugz
Keywords: qawanted
Priority: P4 → P3
This is a showstopper for the next-generation Java Plug-In on X11 platforms since it only works in Firefox 3. Please investigate this ASAP.
Priority: P3 → P2
Do you have, or would you be able to create, a smaller testcase that shows the same issue?

Is source available for the plugin now?  Or an amd64 build?
Sorry, we do not have a smaller test case. However, the HTML involved is not that complex and it seems to me that it should be feasible to track down the problem with the existing test cases.

Also sorry, but the source code for the Java Plug-In is not yet available. However, the currently available 32-bit plug-in should work fine with a 32-bit build of FF 3 even on AMD64 hardware.
Kenneth, I am getting "Failure to Connect To Web Server" errors trying to connect to swinglabs. Can you check on it, please?
Yes, a recent change in the server configuration seems to have broken the app and actually our ability to connect to the app server at all. We are working on this and hope to have it fixed within the next day or two.

If worse comes to worst, I could attach a standalone version of the Iris app which is only partly functional but which would reproduce the incorrect rendering result. Please let me know if you are ready to investigate this bug now and I will create this test case.
If the app can be run from bugzilla easily or downloaded and run without having to do a lot of configuring, installing, etc. I would be willing to investigate the regression range on this today. If it is a pita to get the test case created or installed, I can wait for the server to be fixed.
It's not that much of a pita, but it sounds like the server may be up and running again within an hour or so. If it isn't then I'll zip up a standalone binary and attach it.
I'm sorry this didn't happen today, but the guy who administers the app server just had his second baby, and I've been completely swamped today and unable to produce a standalone version of the test case. Please bear with us and please work with us as soon as we have the test case available.
The server is back up. Sorry for the delay, and please update the bug if you have any trouble finding the regression range.
Tested on Fedora7, Java(TM) Plug-in 1.6.0_04-b12

regressed on 1.8 branch between 2006-04-20-04, 2006-04-21-04 builds
regressed on trunk      between 2006-04-19-03, 2006-04-20-04 builds
Bob: thank you for the regression range.

At this point are we close to a root cause analysis?
Unfortunately the world was checked into the trunk on that day. The checkins on the branch are much more manageable to look at, but nothing stands out to me. I'll use the nightly hourly archive to try to narrow down the checks more later tonight.
Looking at the regression on 1.8 gives 2006-04-20 12:00 pass, 2006-04-20 15:27 fail which points to bug 302536. This doesn't quite jibe with the range I found for the trunk however. Trying to rebuild and run the trunk for the range has been a pita due to selinux warnings and other failures with the builds. Maybe this is enough to help pin point the checkin.
Blocks: 302536
Keywords: qawanted
Karl or Daniel you guys have any cycles for this?
(In reply to comment #25)
I'm a bit full until after beta 3, at least.
Trying to guess what plugins are doing has soaked a lot of time in the past.

Bob, thanks for the analysis.  Comment #0 suggests this was working on branch, and IIRC I had branch working on an Ubuntu system around 2007-11-06.
(In reply to comment #26)
> (In reply to comment #25)
> I'm a bit full until after beta 3, at least.
> Trying to guess what plugins are doing has soaked a lot of time in the past.
> 

Recommendation for other folks who could help?
Assignee: mozbugz → kinetik
Some things that may be worth investigating:

Today's Java plugins register as XEmbed plugins.  For XEmbed plugins, Gecko creates a GtkSocket which includes an X window.  The XID of this window is passed to the plugin for communication of events.  Most XEmbed plugins use a GtkPlug to communicate through this GtkSocket window.  AIUI the GtkPlug creates a child window (of the same size) and uses this child window for drawing.

I doubt Gecko would be drawing to this child window, so I'm wondering whether the Java plugin is not creating a child window.  From a quick look at the Java plugin libraries, I can't see any mention of GTK so I guess they have their own XEmbed implementation.  Perhaps someone at Sun can tell us whether the plugin creates a child window?

Or it may be possible to work it out from
export NSPR_LOG_MODULES=nsObjectFrame:4,Plugin:9,PluginNPP:9,PluginNPN:9
and xwininfo.
Watch out though - there is more than one plugin window at the same time in the problem page here.

Perhaps the Java plugin used to work by drawing to Gecko's GtkSocket window, and perhaps at one time Gecko didn't draw to this window.  If this is what has changed in Gecko, then it could be a change to any of the following:
configure.in
modules/plugin/base/
widget/src/gtk2/
layout/generic/nsObjectFrame.cpp
gfx/
I am 99.99% sure that the XEmbed implementation in the AWT creates a real child window. I have asked a couple of the AWT team members at Sun to sign up for Bugzilla accounts so they can be added to the CC: list of this bug to confirm.

On the Windows platform I am 100% sure that the AWT creates a real Windows "window" which is placed into the HWND that the browser hands us. This is why the overlapping of the plugin only on X11 platforms is so surprising, since it shouldn't be possible for the browser to overlap Java's rendering unless it creates a real window system-level window for the HTML rendering result. Again, I am 99.99% sure that Java portably creates a true window system-level window for the applet.

I suspect that something changed in the page layout engine and it is now fabricating X windows on the X11 platform, perhaps to attempt to implement Z-ordering.
Ken is right, we do create native window for xembed client.
(In reply to comment #31)
> Ken is right, we do create native window for xembed client.
> 
perhaps I should be more clear "we" == AWT :)
The behaviour changed when the patch for bug #334756 landed (2006-04-19 20:31 on trunk, 2006-04-20 15:01 on MOZILLA_1_8_BRANCH), causing the browser user agent to report "Minefield/3.0a1" (on trunk) and "Bon Echo/2.0a1" (on the 1.8 branch) rather than "Firefox/3.0a1" or "Firefox/2.0a1", respectively.  This is trivial to confirm by changing the "general.useragent.extra.firefox" pref via about:config and reloading the Iris application.
Blocks: 334756
No longer blocks: 302536
Er, Kenneth, Son --- is there some user-agent sniffing going on in the plugin???
No.
I've asked a couple of people more familiar with the HTML and JavaScript on the Iris web pages to see whether a change to the user agent might cause the JavaScript and therefore the page rendering to misbehave.
The plugin does query the user agent via NPAPI, but that doesn't seem to be the source of the problem.  To confirm this, I modified nsPluginHostImpl::UserAgent to return a specific user agent.  When it returned Firefox and the true user agent was Minefield, the testcase fails.  When it returned Minefield and the true user agent was Firefox, the testcase passes.

The JavaScript property navigator.userAgent is queried by two scripts in the Iris application: jasper.js and x.js.  jasper.js has a BrowserDetect object that is used in photos.jsp to perform per-browser style manipulation.  BrowserDetect will report the browser as either "Firefox" or "Mozilla" based on whether the user agent contains the substring "Firefox".  photos.jsp has conditional code for "Firefox" (and some other browsers), but not "Mozilla".  The "Firefox" conditional switch style.overflow between "auto" and "hidden" for divs with id="ALBUMS" and id="MAINPAGE".

There must be more to this, because the testcase only fails on Linux, but the style changes based on user agent mentioned above will be happening the same way on each platform.  jasper.js does contain OS detection using navigator.platform, but it doesn't look like Iris uses this at all.
It's probably not a real regression then. The application worked around some Firefox bug, but their browser detection was poor so they accidentally stopped applying the workaround. This should not be a blocker for us, unless we identify the underlying bug the application is working around and fix it. I think it's up to Kenneth or someone else from Sun to tell us what the underlying bug is and give us a decent testcase.

(It's probably something like bug 274600, which is not really fixed even though the reporter resolved it in a strange way. But that's a cross-platform bug.)
Thanks for all of your help in diagnosing this.

You're right, this is not a regression in Firefox 3. I can provoke the same behavior with Firefox 2 on Solaris/x86 by changing the user agent to "Minefield".

The difference in behavior between X11 platforms and Windows is strange, but fairly clearly something we will need to work around in our application.

I am closing this bug as "INVALID".
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.