[EDGY] firefox crashed [@nsObjectFrame::PluginNotAvailable] [@nsPluginInstanceOwner::PluginNotAvailable] [@nsPluginHostImpl::TrySetUpPluginInstance]

[rkabelich]

... Firefox crashed

... after pressing the Back Button

From the Attached Crash Report:
Distro Release: Ubuntu 6.10
System Arch: i686
Package (version): firefox (2.0+0dfsg-0ubuntu3)
Source Package: firefox

Original Description:

Hello,
I had opened 2 Tabs and was pressing the Back Button 3 times. Then Firefox closed himself and asked for restoring information.
In the attachment the crash report.
Regards
Ronald Kabelich

[Elmar-ludwig (elmar-ludwig)]

Created attachment 198552
testcase

Minimal testcase that still crashes for me.

[Ria-klaassen (ria-klaassen)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051004
Firefox/1.4.1 ID:2005100419

I see the same in windows. It crashes only with plugin.default_plugin_disabled
to true.

TB10236036Z
TB10235933Y

[Ria-klaassen (ria-klaassen)]

Regression between 1.8b2_2005062912 and 1.8b2_2005062922.

[Mark Mentovai (mark-moxienet)]

Regression window per comment 3:

http://bonsai.mozilla.org/cvsquery.cgi?branch=HEAD&branchtype=match&date=explicit&mindate=2005-06-29+11%3A00&maxdate=2005-06-29+23%3A00

[Elmar-ludwig (elmar-ludwig)]

This leaves the patch for bug 277434 as the most likely candidate, I guess...

Looking at a build just before 20050629 it seems to me that the CSS rule from
userContent.css just doesn't match (since the <embed> tag is missing the type
attribute), so maybe the change in bug 277434 has just uncovered an older bug.

cc'ing jst as he might have an idea what is wrong here.

[Mark Mentovai (mark-moxienet)]

Not seeing this on the trunk.

[Adam Guthrie (ispiked)]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051207 Firefox/1.6a1

No crash on either trunk or branch, but on branch the Flash still shows up.

[Elmar-ludwig (elmar-ludwig)]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

The minimal testcase still crashes for me on the branch (Firefox 1.5 final).
It does not crash on the trunk, as Mark already mentioned im comment 6.

[Adam Guthrie (ispiked)]

Elmar, is it the same stack still? I still can't seem to get the userContent.css rules to prevent Flash from showing in branch...

[Elmar-ludwig (elmar-ludwig)]

Yes, exactly the same stack as before:

TB12761954H (Firefox 1.5 final)
TB12762284K (latest branch build 2005120804)

Hiding Flash via userContent.css works fine for me here on the branch (apart from the cases where it crashes the browser, of course).

[Bzbarsky (bzbarsky)]

So.... On the one hand I cannot reproduce this crash on branch (1.8.0 Firefox build). Not only can I not reproduce it, but it's not obvious to me how that testcase could crash, given no extensions installed.

On the other hand, it's trivial to write a crash testcase here -- just have an event handler for the event we fire rearrange the DOM (which will kill the frame). With any luck we will then crash when we set mIsBrokenPlugin or mState. If we don't, we'll call mContent->GetDocument() which is virtual. Not good.

The same issues exist on the aviary branch, of course; not sure how much we care about that.

[Bzbarsky (bzbarsky)]

Created attachment 218499
Patch for the issue I do see

I haven't really tested this, largely because I have no idea how. Do we have testcases for this plugin finder stuff somewhere?

Elmar, does this patch fix the crash for you?

[Doronr (doronr)]

We don't have textcases really - I usually just uninstall flash and visit a flash page and check that it installs correctly and all.

[Bzbarsky (bzbarsky)]

That's not going to cut it. For me to have any confidence in landing this on a stable branch (which needs to happen), I need to test it against some testcases that exercise all major aspects of the plug-in finder stuff (at the least, I need to verify that there are no changes in look or behavior, on pages that use all three of object/embed/applet, on pages that do and do not set type attributes, and for both plug-ins that get a URI and plug-ins that do not). This involves knowing what the plug-in finder is supposed to behave like, by the way (or rather which behaviors absolutely need to be tested). Is that documented anywhere?

I can't believe we've been landing changes to this code on "stable" branches without having such tests, and I'd really appreciate if the original authors of the code would point to the tests they used to test their stuff before landing it; ideally said stuff would be in a relevant CVS test directory. Let's do that while said original authors are still around, so we don't have to reverse-engineer this code a few years hence like we're having to do for so much code right now.

[Doronr (doronr)]

I have some testcases back at work, biesi perhaps has some for his XBL work (which might be the most affected by this change). I guess toolkit/mozapps/plugins/tests would be a decent location.

There is no design document for the wizard UI, as I wrote the original stuff late during the aviary release cycle. I could write something on the wiki and then QA could use it to build/write whatever they need.

[Timeless-bemail (timeless-bemail)]

plugin tests should live in plugins or layout, since they are still valid whether or not we have some specific null plugin.

[Bzbarsky (bzbarsky)]

layout/html/tests would be a better location, imho, since we're testing layout code.

That is, the tests should live in layout; the descriptions of how the wizard behaves in response to those tests should live in mozapps as you said. The relationship should be documented in a README in the tests dir.

> There is no design document for the wizard UI

Could one be written please? Better late than never.

Note that imo this is a must for 1.8.0.3, so anything that could be done to expedite me being able to test this and land it so it doesn't miss 1.8.0.3 would be much appreciated...

[Jst (jst)]

Comment on attachment 218499
Patch for the issue I do see

>+ // Make sure to fire the event AFTER we've finished touching out members.

s/out/our/

s+sr+a=jst

[Elmar-ludwig (elmar-ludwig)]

(In reply to comment #12)
> Elmar, does this patch fix the crash for you?

I'm fairly busy this week and building from source takes time. I will see what I can do though.

[Christian Biesinger (cbiesinger)]

the testcases I have are:
http://biesi.damowmow.com/object/033.html
http://biesi.damowmow.com/object/embed_incomplete_and_invalid/033.html

it's not much but the best that I have.

[Doronr (doronr)]

http://www.nexgenmedia.net/mozilla/pfs/tests/ is my current tests.

Four of them:
  - first tests a plugin that doesn't exist
  - second tests flash in embed
  - third tests flash in object
  - fourth tests flash/real in embed

I tried with the patch and see no behavior change. Note that it is best to open each test in a new tab, since we have a regression and aren't clearing the missing plugins list for each tab anymore on the 1.8 branch and trunk.

[Bzbarsky (bzbarsky)]

Awesome. Thanks! Checked in on the 1.8 branch.

Doron, is there a bug for the 1.8/trunk issue you mention in comment 21?

[Doronr (doronr)]

Bug 334674 is about the tabs not clearing their missing plugin data.

[Dveditz (dveditz)]

Comment on attachment 218499
Patch for the issue I do see

approved for 1.8.0 branch, a=dveditz for drivers

[Bzbarsky (bzbarsky)]

Fixed on 1.8.0 branch.

[Twalker (twalker)]

verified with 2.0b2 builds from 20060821

[rkabelich (rkabelich)]

Hello,
I had opened 2 Tabs and was pressing the Back Button 3 times. Then Firefox closed himself and asked for restoring information.
If report is needed, please contact me. I'll Email you the crash report.
Regards
Ronald Kabelich

[David Farning (dfarning)]

Thanks for your bug report. Could you please install firefox-dbg and try to obtain a backtrace (or crash report) by following the instructions on https://wiki.ubuntu.com/DebuggingFirefox This will greatly aid us in tracking down your problem.

Which flash package do you have installed?
Which Java package do you have installed?
Which firefox extensions do you have installed?

Thanks
David

[Matthieu Clavey (matthieu-clavey)]

I had the same type of crash : two tabs opened and then press back button one time on the second tab. Then firefox crashed.

[Freddy Martinez (freddymartinez9)]

Thank you for the bug comments. What kind of systems are you both using? What version of Firefox?

[Hilario J. Montoliu (hjmf) (hmontoliu)]

Retrace done.

Extract from retraced stacktrace:
...
#3 <signal handler called>
#4 nsObjectFrame::PluginNotAvailable (this=0xaffa177c,
#5 nsPluginInstanceOwner::PluginNotAvailable (this=0xafd52d98,
#6 nsPluginHostImpl::TrySetUpPluginInstance (this=0xafdb1eb0,
#7 nsPluginHostImpl::SetUpPluginInstance (this=0xafdb1eb0,
#8 nsPluginHostImpl::InstantiateEmbeddedPlugin (
#9 nsPluginStreamListenerPeer::OnStartRequest (this=0xafd4faf8,
#10 nsHttpChannel::CallOnStartRequest (this=0xafd939b0)
#11 nsHttpChannel::ProcessNormal (this=0xafd939b0)
#12 nsHttpChannel::ProcessResponse (this=0xafd939b0)
...

Tagging as mt-waitdup, mt-needtestcase for further processing

[Hilario J. Montoliu (hjmf) (hmontoliu)]

Retraced Thread Stacktrace

[Hilario J. Montoliu (hjmf) (hmontoliu)]

Is this still an issue for you? We are trying to sort this issue and would like to know if this still happens.

If it can be reproduced, please describe the steps to do it.

Thanks in advance.

[Hilario J. Montoliu (hjmf) (hmontoliu)]

Recent Talkbacks with the same stack;

http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=33254005
http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=33228887

[Hilario J. Montoliu (hjmf) (hmontoliu)]

https://bugzilla.mozilla.org/show_bug.cgi?id=311172 Fixed upstream.