我在用15.0.1

给你们用要等晚上上传

不清楚

你可以把出错的版本给我个链接 我看看

官方出了15.01，有没有跟进？

Lawliet：
那請問有可能是哪裡出了問題嗎？
看我現在的UA，這是剛編好的自動pgo
原本自動打包好的那個調試firefox單獨執行依舊提示xul錯誤
當初不就是用這個進行調試的嗎...回到原帖

不清楚

你可以把出错的版本给我个链接 我看看

用了pcx的x86编译版，几天体验下来感觉比官方版本确实快了很多

我就扔了pgort100.dll进去，其他没动

那請問有可能是哪裡出了問題嗎？
看我現在的UA，這是剛編好的自動pgo
原本自動打包好的那個調試firefox單獨執行依舊提示xul錯誤
當初不就是用這個進行調試的嗎...

Lawliet：剛剛自動pgo編譯到一次編譯結束
有看到調試firefox啟動
自己手動關閉窗口，手動執行也提示同樣的錯誤？！
現在跟以前不一樣了嗎？
不是丟個pgort100.dll進去就好了？
還有別的東西嗎？回到原帖

我就扔了pgort100.dll进去，其他没动

liuxb：基本搞清楚了。

plugins目录放在firefox同目录，或者profiles目录下都是可以的，无所谓。

64位插件无论如何都会自动监测到的。

对于32位插件，
如果是新建配置，一切都正常。
如果是使用已有配置，prefs.js中如果有设置下面这一项的话，必须先删了
user_pref("dom.ipc.plugins.enabled", false);
然后启动，就可以正常识别32位flash插件了，
这个时候，再把dom.ipc.plugins.enabled重新设置为false，也一切正常，呵呵。

系统是Windows 8 x64。


另外，64位firefox用32位插件有什么优势吗？

用你的15.0版的32位和64位的分别跑了http://dromaeo.com/上那个15分钟的推荐测试，32位的性能还是要好点，比64位的高大概不到点10%的样子。

64位的有什么别的优势吗？如果没有，目前还是打算用32位的。回到原帖

奇怪，我改的源码应该是检测dom.ipc.plugins.enabled为true时有效才对……

64位性能显然比不上32位的啊，这个只是为了支持32位插件，提高用户的使用体验，其他64位编译版并没有支持这一功能。

我以后并不着重于性能的提高（现在已经基本到头了，再提高就是完全逆向tete009的tmemutil模块，这中间我卡住了，先放一放），而把精力投入到功能上，比如进一步完善64位支持32位插件补丁（调整优先级之类），比如支持MP4的HTML5标签。

剛剛自動pgo編譯到一次編譯結束
有看到調試firefox啟動
自己手動關閉窗口，手動執行也提示同樣的錯誤？！
現在跟以前不一樣了嗎？
不是丟個pgort100.dll進去就好了？
還有別的東西嗎？

基本搞清楚了。

plugins目录放在firefox同目录，或者profiles目录下都是可以的，无所谓。

64位插件无论如何都会自动监测到的。

对于32位插件，
如果是新建配置，一切都正常。
如果是使用已有配置，prefs.js中如果有设置下面这一项的话，必须先删了
user_pref("dom.ipc.plugins.enabled", false);
然后启动，就可以正常识别32位flash插件了，
这个时候，再把dom.ipc.plugins.enabled重新设置为false，也一切正常，呵呵。

系统是Windows 8 x64。


另外，64位firefox用32位插件有什么优势吗？

用你的15.0版的32位和64位的分别跑了http://dromaeo.com/上那个15分钟的推荐测试，32位的性能还是要好点，比64位的高大概不到点10%的样子。

64位的有什么别的优势吗？如果没有，目前还是打算用32位的。

pcxfirefox：没看出什么问题来

是x86和x64构建过程都是这个错误么？

如果x64也是的话，不太应该，因为你这些补丁基本来源于htguard，没听说他有这个问题回到原帖

加上昨晚，今天總共失敗兩次
htguard我記得他不是用手動採集的betterpgo啊
還是我記錯？

貌似編譯Firefox那麼多人
只有我跟你用類似的方法在編譯而已
tete009的優化方式也跟我的方法不太一樣

我这正相反，
看起来是64位的优先级高。

Generated File. Do not edit.

[HEADER]
Version|0.15|$
Arch|x86_64-msvc|$

[PLUGINS]
NPSWF64_11_2_202_235.dll|$
Z:\firefox\profiles\plugins\NPSWF64_11_2_202_235.dll|$
11.2.202.235|$
1342862968409|0|1|$
Shockwave Flash 11.2 r202|$
Shockwave Flash|$
2
0|application/x-shockwave-flash|Adobe Flash movie|swf|$
1|application/futuresplash|FutureSplash movie|spl|$

[INVALID]
Z:\firefox\profiles\plugins\NPSWF32_11_2_202_235.dll|$
1339227358091|$

liuxb：试了64位的，两个插件都没有检测到
我的flash插件和wmp插件都是单独一个文件非安装版本的，\Profiles\plugins\NPSWF32.dll ，\Profiles\plugins\np-mswmp.dll
这样是不是不支持啊？必须要安装版的，能不能也支持原来的这种在profiles目录下plugins目录中放插件的方式呢？

plugins.dat文件内容：
Generated File. Do not edit.

[HEADER]
Version|0.15|$
Arch|x86_64-msvc|$

[PLUGINS]

[INVALID]
C:\Program Files\Mozilla Firefox\Profiles\plugins\NPSWF32.dll|$
1342866381591|$
C:\Program Files\Mozilla Firefox\Profiles\plugins\np-mswmp.dll|$
1246112858000|$回到原帖

根据这里的说法
http://code.google.com/p/pcxfirefox/issues/detail?id=27

他把两个flash插件放到 $profile/plugins文件夹也能正常识别其中一个

好的，我知道了，謝謝
我已經在編譯了，結果等明天早上再說
我要先睡了

Lawliet：
這次有一個問題似乎只有我
問過htguard，他說他沒遇到
不論編x86還是x64都會提示HarfBuzz錯誤
打上這個patch後解決，這個你也有嗎？
https://bugzilla.mozilla.org/show_bug.cgi?id=780409回到原帖

这个问题在Unicode开发时经常遇到，尤其是CJK用户
我怀疑htguard用的是英文版系统（C反正100%遇到，J/K用户不清楚）

那么通常解决方法有二：
1、切换系统地区区域语言指英文
2、把出错的源码转成带BOM的UTF-8编码（用npp之类的转转即可）

如果x64也是的话，不太应该，因为你这些补丁基本来源于htguard，没听说他有这个问题

這次有一個問題似乎只有我有
問過htguard，他說他沒遇到
不論編x86還是x64都會提示HarfBuzz錯誤
打上這個patch後解決，這個你也有嗎？
https://bugzilla.mozilla.org/show_bug.cgi?id=780409