問題タブ [firebreath]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
0 に答える
350 参照

google-chrome-extension - npapi プラグイン (Firebreath による) は外部ページから呼び出すことができますが、chrome 拡張ページからは呼び出すことができません。

npapi プラグインは、FBTestPlugin を少し変更したものです。

プラグインは現在、マニフェストでパブリックに定義されています。これで、プラグイン メソッドを外部ページから呼び出すことができます。しかし、拡張機能のどのページにもありません。背景ページとオプションページを試しました。オプション ページにrunProxy()メソッドがあり、外部ページと同じことを行いますが、プラグイン オブジェクトによってメソッドが見つかりません。

こちらからChrome 拡張機能をダウンロードして、試してみてください。

コマンドラインを使用して、Linuxでデバッグしました

そして、これがおそらく問題であることがわかりました。

しかし、安全上の理由から、プラグインを非公開 (拡張ページと呼ばれるだけ) に定義できることを望みます。直し方?

0 投票する
1 に答える
669 参照

c++ - C++: Firebreath を使用して複数のインスタンスでビットマップを描画する

私はこれに苦労しています、

GDI+ を使用して Bitmap を PluginWindowWin (Firebreath) に描画したい。そのために、今のところ wm_paint メッセージをシミュレートするタイマーがあり、内部に次のコードがあります。

imageGdiplus::Imageで、正常に動作しますが、プラグインの 2 つのインスタンス (2 つの異なる HWND) を作成すると、そのうちの 1 つにのみ描画されます。

それは予想される動作ですか?つまり、GDI+ は HWND から作成された 1 つのコンテキストでのみ描画しますか?

ありがとう!

0 投票する
2 に答える
1418 参照

c# - C++ と C# の間のサイド バイ サイド依存関係

FireBreath Framework を使用してブラウザ プラグインを作成しています。ほとんどのロジックは C# で記述されており、ブラウザから呼び出すために C++ ラッパーを作成しました。ブラウザーは、C# プロジェクトで実際のロジックを呼び出す「プロキシ」マネージ C++ コードを呼び出す C++ ネイティブ コードを呼び出します。

だから私は3つのdllを持っています:

  • Managed C++ に依存する head ネイティブ C++ dll。
  • C# に依存するマネージ C++。
  • メイン ロジックを含む C# dll。

ユーザー ディレクトリにインストールされた 3 つの dll すべて (c:\Users\\AppData\Roaming\MyCompany\MyApp\1.0.0.0)

問題は、ブラウザーが C# dll をロードしないことです。Side by Side マニフェストを使用して依存関係を宣言します。

アセンブリを宣言する別のマニフェスト ファイルを作成しようとしました。

この依存関係へのリンクをヘッド dll (ネイティブ C++) に追加しました。

また、ヘッド dll (ネイティブ C++) で直接依存関係を宣言しようとしました。

#pragma ディレクティブを使用して依存 dll をリンクしようとしました:

Dependency Walker を使用して依存関係を確認したところ、Managed C++ と C# の間に存在しない依存関係が確認されました。

プラグインは head dll (ネイティブ C++) にアクセスでき、Managed C++ もロードしますが、Managed C++ が C# dll を呼び出すと、プラグインが失敗し、C# アセンブリが見つかりません。

C# dll をブラウザ アプリケーション (firefox.exe または chrome.exe) と同じディレクトリに配置すると、動作します。

Managed C++ と C# の間で Side By Side 依存関係が機能しないようです。

プラグインに依存する dll をロードするにはどうすればよいですか?

0 投票する
1 に答える
228 参照

npapi - FireBreath はシステム パスを見つけます

私はfirebreathが初めてで、Google Chrome拡張機能にパッケージ化されるNPAPIプラグインを開発しています。DLL が現在どこにあるかを取得するメソッドの作成に問題があります。何かアイデアはありますか?

0 投票する
1 に答える
288 参照

javascript - ブラウザー ウィンドウでのパイプ出力の効率的なスクロール

ユーザーのマシンでローカル プロセスを呼び出し、stdout をブラウザーに戻すカスタム ブラウザー プラグイン (FireBreath で構築) があります。これを行うには、popen() 呼び出しを介してプロセスを実行し、パイプ JSAPI イベントを発生させ、ブラウザに送り返します。

ブラウザーで、出力をフォーマット済みのテキストとして div に追加し、div に一番下までスクロールするように指示します。

ブラウザ プラグインのコード:

HTML & Javascript/jQuery:

この方法は、私が必要とするブラウザでは機能しますが (これは内部ツールの使用が制限されています)、イライラするほどラグがあります。私のプロセスは通常、出力ウィンドウのスクロールが完了する 30 ~ 60 秒前に終了します。では、これをより効率的にするにはどうすればよいでしょうか。このテキストをブラウザに戻すより良い方法はありますか?

0 投票する
1 に答える
593 参照

c++ - FireBreath フレームワークで Win32 API CreateProcess を使用する

Firebreath フレームワークを使用してブラウザ プラグインを開発しようとしています。私が達成したい最初のことは、プラグインが traceroute を実行できるようにすることです。今のところWindows7でやっています。現在、Win32API CreateProcess を使用してコマンド シェルを呼び出すことにしました。dwFlags = STARTF_USESHOWWINDOW を設定することで、実行中にコマンド シェル ウィンドウを非表示にすることができます。

問題 : createProcess は run() というメソッドに実装されており、テストのために JS を使用して呼び出しました。plugin().run() を呼び出したところ、traceroute は正常に機能しており、出力は意図したとおりにテキスト ファイルに正常に書き込まれました。ただし、実行中にブラウザが応答しなくなり、traceroute が完了してからプラグインが最後にクラッシュしました。私はプラグイン開発が初めてで、 c++ に関する知識がほとんどないため、なぜこの問題が発生したのだろうか。参考までに、コマンドシェル ウィンドウを非表示にしなかった場合、プラグインは驚異的に機能しました。traceroute の実行中、ブラウザは応答していました。

0 投票する
1 に答える
1403 参照

javascript - Firebreath JavaScript エラー: サポートされていません: 関数型に toString() 関数がありません

firebreath フレームワークを使用してブラウザ プラグインを作成しています。JavaScript でプラグインを使用すると、奇妙なエラーが発生します。

JSAPIPtr を返す Dropbox_pluginAPI クラスのメソッドを数回呼び出そうとすると、このエラーが発生します。

コードは次のとおりです。

誰かがfirebreathで働いて、私を助けてくれることを願っています!


Firefox のバージョンを更新し、断片を別の行に分割しましたが、それでもエラーが発生します。私は次のことをしました:

アラートが呼び出されることはありません。いくつかの呼び出しの後、まだエラーがあります:

列をなして:

0 投票する
1 に答える
355 参照

c++ - ブーストとFirebreathを使用してPython内からブラウザイベントを適切に発生させる方法

最初に言わなければならないのは、Python プログラマーとして、この問題を間違った視点から見ている可能性があるということです。大学時代に最後の C++ コードを書いてから何年も経ちました。

firebreath を使用してハイブリッド python/c++ プラグインを作成しようとすると、少し問題が発生します。これまでのところ、boost/python.h を使用してすべてのパーツを統合することに成功していますが、python 内からイベントを発生させようとすると問題が発生しました。Python 関数と C++ 関数を (BOOST_PYTHON_MODULE を使用して) バインドする必要があるという問題に遭遇しました。最初に、Python を JSAPI 派生クラス fbtestconpythonAPI に直接バインドしようとしましたが、このアプローチの問題は、ブラウザーによってインスタンス化された JSAPI オブジェクトへの参照がないことのようで、Python 関数と同等の C++ の間であらゆる種類の署名の不一致の問題が発生します。実行時間。

これを修正するために私に起こった唯一のこと(同意します、醜い汚い解決策です)は、set_pluginPointerで手動で初期化するグローバルポインターを使用することです。これは実際にはこれまでのところかなりうまく機能していますが、正しい方法ではないことはわかっています。JSAPI オブジェクトで「生の」ポインタを使用してはならないことを読みましたが、この特定の実装でそれを shared_ptr に置き換える方法がわかりません。もう 1 つの問題は、すべてのインスタンスで共有されるグローバル変数です。たとえば、最後に開いたタブ/ウィンドウですべてのイベントが発生します。後者を解決する 1 つの方法は、インデックスが現在のウィンドウ/スレッド ID であるある種の配列を作成することです。これは、JSAPI オブジェクトと python/c++ 関数の両方からアクセスできるはずです。

もちろん、私はオープンであり、この特定の回避策を改善/修正する方法、またはハッキングせずに boost::python と firebreath を通信する正しい方法についての提案を非常に高く評価します。

以下は、プラグインコードの関連部分です

0 投票する
1 に答える
805 参照

google-chrome - 可視領域が変更されると OpenGL プラグインが Chrome をクラッシュさせる

WindowsでFireBreathを使用してプラグインを開発しています(今のところ)、OpenGLを使用してウェブカメラフィードを表示しています。ウィンドウプラグインを使用しており、別のスレッドから描画しています。コードは次の場所で表示できます。

ヘッダーファイル

https://github.com/EvilTengil/kinect-at-home-plugin/blob/0007beecf136ff2e5e1aa50be94d4906447a8f43/Win/KinectAtHomeWin.h

ソースファイル

https://github.com/EvilTengil/kinect-at-home-plugin/blob/0007beecf136ff2e5e1aa50be94d4906447a8f43/Win/KinectAtHomeWin.cpp

(onWindowResized の奇妙なコードは無視してください。これは、コミットに残っているいくつかのテストです。)

問題は、ブラウザー ウィンドウのサイズが変更されてプラグインの表示領域が変更されるか、拡張機能が何らかの理由でスクロール ボックスの表示領域の外にスクロールされるとすぐに、Chrome でプラグインがクラッシュすることです。Firefox はインストールしていませんが、Internet Explorer で動作しているので、NpApi のことだと思います。

プラグインの表示サイズが変更されるたびに、Chrome が新しい HDC をリリースして作成することが起こっていると思います。これにより、レンダリング コンテキストが無効になる可能性がありますが、プラグインでまだ使用されているため、クラッシュが発生します。

これが発生したときに NPP_SetWindow get が呼び出されることに気付きましたが、これらの呼び出しは NpapiPluginModule_NPP.cpp で無視されるため、このイベントにフックする方法はありません。

私は数時間Googleを使っていますが、何の助けも見つかりません. 誰もこれを経験したことがありますか?

自分のDCを処理できるプラグインウィンドウに自分の子ウィンドウを作成すればうまくいくと思います。私は失敗した簡単なテストをいくつか行いました。しかし、これはもう少し作業を加えるとうまくいくでしょうか?私が持っている別のアイデアは、何らかの方法で可視領域を追跡することですが、まだ調べていません。

0 投票する
2 に答える
444 参照

c++ - Visual Studio を使用して静的にビルドされたライブラリを共有ライブラリにリンクすることによる潜在的なメモリ リスク

Windows でクラッシュするクロスプラットフォームの Firebreath プラグインに取り組んでいます。boost.asio を参照するクラスを含む静的ライブラリを使用します。このライブラリをプラグイン dll に対してリンクすると、io_service サブシステムと対話するとき (つまり、ソケットの構築中) にクラッシュが発生します。通常の実行可能ファイルに対して静的ライブラリをリンクすると、問題は発生しませ。スタティック ライブラリの内容をプラグイン dll プロジェクトに直接コンパイルすると、クラッシュは発生しません。発生する。私は、Windows 上のビルド環境のすべての側面 (ビルド モード、Visual Studio のバージョンなど) が一貫していることを確認するために多大な努力を払ってきました。さらに、プラグイン dll コードが boost.asio サブシステムを認識できないように、boost.asio ヘッダーをファイアウォールで保護しました (残念ながら、vs2008 と vs2010 では効果がありません)。私が知る限り、ビルド環境が適切に動作するようにできる限りのことを行いましたが、問題は解決しません。

コミュニティは、潜在的なリスクや、問題を明らかにしたり解決したりする可能性のあるアプローチについてアドバイスを提供できますか?