Bug 30775 - [Qt] QWebPluginInfo::isNull() should be QWebPluginInfo::isValid()?
Summary: [Qt] QWebPluginInfo::isNull() should be QWebPluginInfo::isValid()?
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Qt (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: Qt, QtTriaged
Depends on:
Blocks:
 
Reported: 2009-10-26 07:54 PDT by Benjamin Poulain
Modified: 2014-02-03 03:15 PST (History)
7 users (show)

See Also:


Attachments
Patch (11.70 KB, patch)
2009-11-03 07:37 PST, Simon Hausmann
no flags Details | Formatted Diff | Diff
Patch (12.34 KB, patch)
2009-11-03 07:46 PST, Simon Hausmann
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Poulain 2009-10-26 07:54:33 PDT
QWebPluginInfo::isNull() return true if the QWebPluginInfo has been constructed with the default constructor.

There is no way to know if a QWebPluginInfo is valid after QWebPluginDatabase::refresh(). QWebPluginInfo::isNull() could be changed in QWebPluginInfo::isValid() and be used for the default constructor and for plugins that have become invalid.
Comment 1 Tor Arne Vestbø 2009-10-27 06:44:50 PDT
I propose we make this class private in 4.6, it's not ready for prime time.
Comment 2 Kenneth Rohde Christiansen 2009-10-27 07:12:46 PDT
What are the primary concerns?
Comment 3 Tor Arne Vestbø 2009-10-27 07:33:17 PDT
It's a pretty thin wrapper around PluginDatabase/PluginPackage, ie. we're exposing quite a few internals. This results in tricky stuff like what happens if you refresh plugins but have a QWebPluginInfo that points to one of the plugins that were removed? Now it suddenly has a dangling pointer, etc. Basically I'm worried that not all use-cases have not been thought trough (typical for API around already existing functionality), and we end up exposing bugs like this.

Add to that that this is really QWeb_Netscape_PluginDatabase, ie has nothing to do with the QWebFactoryPlugins. I tried to proxy this in, but it was a bit hairy.
Comment 4 Kenneth Rohde Christiansen 2009-10-27 07:46:26 PDT
OK I agree, it would be totally acceptable to make this a private API for 4.6.

I can have a look at that if you'ld like
Comment 5 Kenneth Rohde Christiansen 2009-10-27 11:40:24 PDT
Laszlo what is your comments on this? What are your requirements for such an API, and when do you need it?
Comment 6 Simon Hausmann 2009-11-03 05:53:34 PST
Jakub, we have concerns regarding the API and given our current release pressure we'd like to delay this API. AFAICS Arora is not using these classes yet. Would you mind if we hold this off for a little while longer?
Comment 7 Simon Hausmann 2009-11-03 07:37:32 PST
Created attachment 42380 [details]
Patch
Comment 8 Simon Hausmann 2009-11-03 07:46:14 PST
Created attachment 42382 [details]
Patch
Comment 9 Simon Hausmann 2009-11-03 07:55:39 PST
Committed r50456: <http://trac.webkit.org/changeset/50456>
Comment 10 Simon Hausmann 2009-11-03 07:56:56 PST
Re-opening and removing dependency on Qt 4.6 API blocker. Technically this bug is still open, but with the committed patch it's not public API at the moment.
Comment 11 Simon Hausmann 2009-11-03 07:57:57 PST
Comment on attachment 42382 [details]
Patch

Clearning review after landing.
Comment 12 Jocelyn Turcotte 2014-02-03 03:15:52 PST
=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.