Re: Question: "Chrome file doesn't exist: ..." in |make mozmill| log by running DEBUG versions of C-C TB

[Stefan Sitter]

On 23.11.2015 06:00, Philip Chee wrote:

On 22/11/2015 03:20, ISHIKAWA,chiaki wrote:

100 Chrome file doesn't exist:
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/classic/skin/classic/messenger/icons/dropbox.png


Was removed in Bug 763471 - Convert Dropbox Filelink provider code to
addon

Try using box-logo.png instead.


Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1227261

/Stefan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: November 16th to November 20th

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Manual QA 
team last week (Week 47: November 16 - November 20).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL*
SeverityID  Summary Status  Resolution  Is a regression 
Assigned to
NORMAL  1225466 
Several issues with Edge migration on newer builds of Windows 10
NEW 
NO  NOBODY
NORMAL  1225780 
	[MAC] Browser_set_ default_error histogram is true while setting 
Firefox as default browser

NEW 
NO  NOBODY
NORMAL  1225814 
	[Ubuntu] Browser_set_ default_time_to_completion_seconds histogram does 
not appear in about:telemetry

NEW 
NO  NOBODY
NORMAL  1226607 
[Linux] "N" character from the "No conversation yet" text is cropped
NEW 
YES  NOBODY



*AURORA CHANNEL*
SeverityID  Summary Status  Resolution  Is a regression 
Assigned to
CRITICAL1225829 
crash in std::_Atomic_fetch_add_4
NEW 
YES  NOBODY
NORMAL  1226145 
On-screen keyboard not displayed for an already focused text field
NEW 
NO  NOBODY
NORMAL  1226148 
On-screen keyboard closes while focusing a text field using OSK Tab key
NEW 
NO  NOBODY


*NIGHTLY CHANNEL*
SeverityID  Summary Status  Resolution  Is a regression 
Assigned to
NORMAL  1225102 
about:telemetry/Add-ons Details data is not accurate
NEW 
NO  NOBODY
NORMAL  1225098 
Browser default dialog rowcount histogram increases incorrectly
NEW 
NO  NOBODY
NORMAL  1226522 
On-screen keyboard not displayed on Dell Inspiron All-in-one
NEW 
NO  NOBODY


*ESR CHANNEL*
none


Regards,
Andrei Vaida| QC Team Lead

SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania
Email: andrei.va...@softvision.ro  | 
Web: www.softvision.ro 


The content of this communication is classified as SOFTVISION 
Confidential and Proprietary Information.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Single- vs. double-precision FP in gfx types

[Robert O'Callahan]

On Tue, Nov 24, 2015 at 4:45 PM, Nicholas Nethercote  wrote:

> One major remaining Moz2Dification step is the conversion of thebes
> types such as gfxSize, gfxPoint, gfxRect, and gfxMatrix to their Moz2D
> equivalents. But this is largely blocked by the fact that the thebes
> types use double-precision FP values while the Moz2D types use
> single-precision FP values.
>
> The difference in precision doesn't matter... except when it does.
> Here are four cases I've seen where a proposed change has been blocked
> by this issue:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=984278#c10
> https://bugzilla.mozilla.org/show_bug.cgi?id=1224093#c2
> https://bugzilla.mozilla.org/show_bug.cgi?id=1222325#c0
> https://bugzilla.mozilla.org/show_bug.cgi?id=1216396#c5
>
> It seems like the strategy so far has been to just make the changes,
> and then insert double-precision when it seems like it's necessary --
> the existence gfx::RectDouble is evidence of this. But it's hard to
> know when it is necessary.
>
> Another possibility would be to just change the Moz2D types to use
> double-precision, which presumably would avoid problems like the above
> ones. But I suspect that will have some opposition, perhaps for
> performance reasons and perhaps because Moz2D's use of
> single-precision mirrors some of the graphics APIs that Moz2D
> interfaces with.
>
> I'd love to find a way to break the current impasse, because
> Moz2Dification will never be completed otherwise; it has certainly
> halted my efforts on that task.
>

I think for now we should focus on replacing usage of gfxContext with
DrawTarget. I think that's more important than unifying those types.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Startup cache and resource:// urls

[Mike Hommey]

Hi,

I recently found out, while refactoring some parts of `make package`,
that since Firefox 38, we've stopped shipping startup cache data for all
the browser javascript modules and components. This turned out to be the
consequence of resource://app/ having been overridden to point somewhere
different from where it's supposed to point to.

I landed a fix for this issue this morning (bug 1224000 ; the fun part
is that it uncovered another bug: bug 1226119)

Anyways, there are three things that I take out of this:

- Startup cache is either useless, or we failed to measure the startup
  time regression in Firefox 38. Either way, something should be done:
  either we don't need the startup cache anymore and we should plain
  remove it, or talos should catch such regressions if they exist. I
  guess we'll see if talos catches some improvements on the fix...
  Can the perf team look into this? Note the startup cache only matters
  on the first startup for a given build, and that might be a reason why
  we fail to track its performance impact.

- resource:///, resource://gre/ and resource://app/, which are used by
  chrome code and possibly addons, are not fixed in stone and can be
  replaced by mistake. This should not be possible, and I filed bug
  1225384 for that (patch pending review).

- The change of meaning for resource://app/ may inadvertently have
  broken addons relying on it, and if it did, it's a problem that we
  haven't gotten aware of it earlier.  ISTR we can do code search on
  addons, but I never know where to look for this.
  Most code in Firefox itself fortunately uses resource:/// instead of
  resource://app/ (they have the same meaning, or at least were supposed
  to, since the bug broke this promise), so it was fortunately not a
  direct problem for Firefox itself.

There's kind of a 4th item to add to the list: that we can have missing
startup cache is also a problem on itself, but it's really tied to the
second issue, since the startup cache generation script relies on
resource://app/ resolving to what it's supposed to in the first place.

Cheers,

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Startup cache and resource:// urls

[Kris Maglione]

On Tue, Nov 24, 2015 at 02:22:44PM +0900, Mike Hommey wrote:

 Note the startup cache only matters
 on the first startup for a given build, and that might be a reason why
 we fail to track its performance impact.


Presumably also when we flush the startup cache for changes in 
add-ons?



 Most code in Firefox itself fortunately uses resource:/// instead of
 resource://app/ (they have the same meaning, or at least were supposed
 to, since the bug broke this promise), so it was fortunately not a
 direct problem for Firefox itself.


I've never seen resource://app/ used in an add-on. Just about 
all of the uses MXR can find[1] are either in Thunderbird 
add-ons, or are appalling hacks like this in themes:


   list-style-image: url("jar:resource://app/omni.jar!/chrome/toolkit/skin/classic/global/tree/twisty-clsd.png"); 


[1] https://mxr.mozilla.org/addons/search?string=resource%3A//app/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Does the sdk/page-worker are loading pages off-main thread? and running code in another thread?

[Yonggang Luo]

pageWorker = require("sdk/page-worker").Page({   contentScript:
"console.log(document.body.innerHTML);",   contentURL: "
http://en.wikipedia.org/wiki/Internet; });

-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Startup cache and resource:// urls

[Mike Hommey]

On Mon, Nov 23, 2015 at 10:26:39PM -0800, Kris Maglione wrote:
> > Most code in Firefox itself fortunately uses resource:/// instead of
> > resource://app/ (they have the same meaning, or at least were supposed
> > to, since the bug broke this promise), so it was fortunately not a
> > direct problem for Firefox itself.
> 
> I've never seen resource://app/ used in an add-on. Just about all of the
> uses MXR can find[1] are either in Thunderbird add-ons, or are appalling
> hacks like this in themes:
> 
>list-style-image: 
> url("jar:resource://app/omni.jar!/chrome/toolkit/skin/classic/global/tree/twisty-clsd.png");

... which seems to be a *very* old thing because:
- resource://app might have pointed to the plain Firefox directory where
  you could find the omnijar a long time ago (I don't remember if that
  ever was actually true), but it points *inside* the omnijar now.
- omni.jar was renamed omni.ja a loong time ago.

Arguably, the interesting test, though, would be addons sources from
before FF38, since presumably addons might have changed to work around
the resource://app brokenness.

> [1] https://mxr.mozilla.org/addons/search?string=resource%3A//app/

Note this url is behind a "AMO Admins - LDAP Login" authentication
(which I probably don't have)

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Question: "Chrome file doesn't exist: ..." in |make mozmill| log by running DEBUG versions of C-C TB

[ISHIKAWA,chiaki]

On 2015/11/23 14:00, Philip Chee wrote:

On 22/11/2015 03:20, ISHIKAWA,chiaki wrote:


  100 Chrome file doesn't exist:
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/classic/skin/classic/messenger/icons/dropbox.png

Was removed in Bug 763471 - Convert Dropbox Filelink provider code to addon

Try using box-logo.png instead.




Replacing the said filename in a test javascript source file caused the
message to go away!


Chrome file doesn't exist (checked since Apri 2, 2015)



113 Chrome file doesn't exist: 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/messenger/content/messenger/messengercompose/null
 35 Chrome file doesn't exist: 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/toolkit/skin/classic/global/icons/information-64.png
  2 Chrome file doesn't exist: 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/toolkit/skin/classic/mozapps/plugins/notifyPluginOutdated.png
  2 Chrome file doesn't exist: 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/toolkit/skin/classic/mozapps/plugins/notifyPluginBlocked.png
  2 Chrome file doesn't exist: 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/classic/skin/classic/messenger/messengercompose/compose-toolbar.png
  2 Chrome file doesn't exist: 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/classic/skin/classic/messenger/icons/mail-toolbar-small.png
  1 Chrome file doesn't exist: 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/toolkit/skin/classic/mozapps/extensions/stripes-info-negative.png


I will file a bugzilla entry.

Does anybody have an idea of the issue of

> 113 Chrome file doesn't exist: 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/messenger/content/messenger/messengercompose/null


"null" can't be right.

TIA

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Single- vs. double-precision FP in gfx types

[Nicholas Nethercote]

Hi,

One major remaining Moz2Dification step is the conversion of thebes
types such as gfxSize, gfxPoint, gfxRect, and gfxMatrix to their Moz2D
equivalents. But this is largely blocked by the fact that the thebes
types use double-precision FP values while the Moz2D types use
single-precision FP values.

The difference in precision doesn't matter... except when it does.
Here are four cases I've seen where a proposed change has been blocked
by this issue:

https://bugzilla.mozilla.org/show_bug.cgi?id=984278#c10
https://bugzilla.mozilla.org/show_bug.cgi?id=1224093#c2
https://bugzilla.mozilla.org/show_bug.cgi?id=1222325#c0
https://bugzilla.mozilla.org/show_bug.cgi?id=1216396#c5

It seems like the strategy so far has been to just make the changes,
and then insert double-precision when it seems like it's necessary --
the existence gfx::RectDouble is evidence of this. But it's hard to
know when it is necessary.

Another possibility would be to just change the Moz2D types to use
double-precision, which presumably would avoid problems like the above
ones. But I suspect that will have some opposition, perhaps for
performance reasons and perhaps because Moz2D's use of
single-precision mirrors some of the graphics APIs that Moz2D
interfaces with.

I'd love to find a way to break the current impasse, because
Moz2Dification will never be completed otherwise; it has certainly
halted my efforts on that task.

Thanks.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Startup cache and resource:// urls

[Kris Maglione]

On Tue, Nov 24, 2015 at 04:08:56PM +0900, Mike Hommey wrote:

... which seems to be a *very* old thing because:
- resource://app might have pointed to the plain Firefox directory where
 you could find the omnijar a long time ago (I don't remember if that
 ever was actually true), but it points *inside* the omnijar now.
- omni.jar was renamed omni.ja a loong time ago.


Quite. There are some older ones, though:

list-style-image: url("jar:resource://app/chrome/classic.jar!/skin/classic/browser/Toolbar-small.png") !important; 


And some more recent ones:

list-style-image: url("resource://app/chrome/browser/skin/classic/browser/Toolbar.png") !important; 


[1] https://mxr.mozilla.org/addons/search?string=resource%3A//app/


Note this url is behind a "AMO Admins - LDAP Login" authentication
(which I probably don't have)


Any MoCo or MoFo account should have access by default.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Startup cache and resource:// urls

[Mike Hommey]

On Mon, Nov 23, 2015 at 11:29:05PM -0800, Kris Maglione wrote:
> On Tue, Nov 24, 2015 at 04:08:56PM +0900, Mike Hommey wrote:
> >... which seems to be a *very* old thing because:
> >- resource://app might have pointed to the plain Firefox directory where
> > you could find the omnijar a long time ago (I don't remember if that
> > ever was actually true), but it points *inside* the omnijar now.
> >- omni.jar was renamed omni.ja a loong time ago.
> 
> Quite. There are some older ones, though:
> 
> list-style-image: 
> url("jar:resource://app/chrome/classic.jar!/skin/classic/browser/Toolbar-small.png")
> !important;
> 
> And some more recent ones:
> 
> list-style-image:
> url("resource://app/chrome/browser/skin/classic/browser/Toolbar.png")
> !important;

Note, depending on what those addons are trying to achieve with those,
it can be considered our fault that we don't have stable urls to access
data for themes (or locales, for that matter) that are not the current one.

Also note that the last form is valid but is currently broken.

> >>[1] https://mxr.mozilla.org/addons/search?string=resource%3A//app/
> >
> >Note this url is behind a "AMO Admins - LDAP Login" authentication
> >(which I probably don't have)
> 
> Any MoCo or MoFo account should have access by default.

Oh, it works.

So, if I believe this:
- https://mxr.mozilla.org/addons/source/4891/content/config.js#69
  Vimperator's import command is broken
- 
https://mxr.mozilla.org/addons/source/221523/components/nsIPXLNotificationCenter.js#165
  HTML5 Notifications might be broken
- https://mxr.mozilla.org/addons/source/242697/chrome/content/places.js#36
  https://mxr.mozilla.org/addons/source/242697/chrome/content/qrcode.js#233
  ViewMarks is likely broken

... and I stopped about halfway through the list and didn't look
thoroughly at the skin related things.

So I guess there are "only" probably less than a dozen addons actively
broken, but it might still be worth pushing for an uplift of the fix so
as to get it into 43.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Why there is no load events for iframe that resident in html page with 'System permission'

[Yonggang Luo]

Is there any security policy here or other things need to do.

-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform