gmane.comp.mozilla.devel.dom

Re: מדוע בישראל לא מרוויחים

סניף ארה"ב - המכון לאבחון עסקי — 2013-05-24T17:20:02

 

 

שלום. בהמשך לחשיפת מחקרנו בערוץ 10 – 

94 אחוז מהעסקים בישראל לא מרוויחים מספיק

 

במהלך 13 השנים האחרונות, לאחר שבחנו מעל 12 אלף עסקים מכל הסוגים בישראל
ובארצות-הברית, גילינו שעסקים רבים בישראל יכולים היו לעמוד על רווחים כספיים
גבוהים בהרבה, אם לא מספר טעויות שנעשות על ידם.

 

בחג האחרון הוקצו מספר מושבים חינם לסדנא מתנה לבעלי העסקים בישראל, בה יפורטו
כל הטעויות שבגללן רוב בתי העסק בישראל לא מרוויחים מספיק.

 

המרצה הוא מחבר רב המכר "האם שווה להיות עצמאי?", יועץ בינלאומי בעל ניסיון
עצום בהגדלת רווחים של עסקים תוך זמן קצר.

 

הסדנא תתקיים ביום שני, 3 לי

Re: Obscure error in FF20

Boris Zbarsky — 2013-04-15T17:23:49

Thank you.  Let's follow up there....

-Boris

Re: Obscure error in FF20

Arnaud Didry — 2013-04-15T17:08:28

Hi Boris,

Thank you for your response, I filed a ticket on bugzilla : https://bugzilla.mozilla.org/show_bug.cgi?id=861947

We don't have much more informations, but we're now sure that the error happens on this check `node.id.tagName`. Hope this helps a little.

For now we are going to monkey patch YUI3 to remove the checks against IE<8 for FF20.

Thanks

Arnaud


Le vendredi 12 avril 2013 20:14:09 UTC+2, Boris Zbarsky a écrit :

Re: Obscure error in FF20

Boris Zbarsky — 2013-04-12T18:14:09

That's certainly the error you'd get if something that's not an element 
has an element method called on it...


That's quite odd, for sure!

Are you able to log any information about this when it fails?  Knowing 
node.localName would really help.


_That_ indicates some sort of JIT bug to me, unfortunately.  :(  I guess 
that answers my question about logging...

What if you put the try/catch higher up the callstack?


Please, with whatever information you have!

-Boris

Obscure error in FF20

Arnaud Didry — 2013-04-12T10:49:22

Hi,

We are experiencing random and obscure errors since the FF20 update : "TypeError: Value does not implement interface Element". 

The stack trace always point to the same line of code : `if (node.id && !node.id.tagName && !node.id.item) {id = node.id;}` (from YUI3 [1]). The caller also ensure that `node.nodeType === 1` [2]

Another particularity of the bug is that it seems to always occurs inside an IndexedDB callback.

We're still trying to find a way to produce a failing test case. We deployed a patch which wrap the line in a try/catch to log the `node` variable but since then the error doesn't seems to occur anymore.

It seems related to the bug #821606 [3]. Do you think of something else which can cause this ? 

Should I file a ticket on bugzilla ?

Thanks !

Arnaud


[1] https://github.com/yui/yui3/blob/v3.8.0/src/dom/js/dom-core.js#L62-L63
[2] https://github.com/yui/yui3/blob/v3.8.0/src/dom/js/selector-native.js#L220
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=821606

rendering the DOM to a canvas

Paul Frazee — 2013-04-04T15:20:10

I want to start playing with the Oculus Rift and Web software in the near future, and re-implementing HTML rendering in WebGL is a black hole I want to avoid. If the Web has any possible clear advantage over any other 3d platform, it's a well-established and well-featured backlog of 2d interfaces. (The on-demand networked VM is pretty good too.) Point is, it's not something I want to implement from scratch, but it's also not something I want to drop off the roadmap.

What I've found so far: html2canvas and rasterHTML (the latter of which uses the SVG trick) are close, but screwy in their own ways, and far less performant (try getting input events going or rendering the cursor blink). Using THREE.js, it's possible to do a "2pass render" (a webgl canvas overlaid on divs that are 3d transformed by css) but the Oculus Rift requires the scene to be rendered twice, then have a pixel shader applied to counter lens distortion.

Some thoughts on solutions:

 - A fully-featured 3d html & css toolset. I think this coul

Re: On the possibility of using the HTML5 parser from C++

Boris Zbarsky — 2013-02-14T16:32:38

First of all, parser/htmlparser is not an HTML5 parser.  It's the old 
tagsoup parser.  The HTML5 parser is in parser/html.

Second, neither one is really designed as a standalone drop-in parser, 
though the HTML5 parser is maybe closer to it...


libxul.


Yes, probably, but you'll be pulling in all of libxul.

You may want to talk to Henri Sivonen about using the translate-to-C++ 
bits or http://about.validator.nu/htmlparser/ as part of your project... 
that's basically what parser/html is.

-Boris

On the possibility of using the HTML5 parser from C++

JDE — 2013-02-14T15:48:27

Dear all:

 Sorry if this is not the right group but it seemed to me the most 
appropriate. If not, could please someone redirect me to the right one?

 My question is about the possibility of using the library contained
in the mozilla global tree under parser/htmlparser to parse a HTML5 file
(local file, not downloaded) from a C++ program and getting the DOM
tree so that my program can transform the HTML file.

 I have succesfully built Firefox, and consequently all the files in 
parser/htmlparser. My questions are:

-In which library have their object code been included? Is it possible to
link an independet program that uses it?

-Is there any documentation from the author(s) of the library (apart from 
the comments in the files themselves) the document the API?

 Thank you very much in advance for your responses.

  Juan

Re: Getting tab URL in C++

2013-01-04T05:57:56

Hi Vaibhav,

I am also implementing the c++ code to get all opened firefox url.

Could you please send me your code.

regards
Pushpendra

On Monday, April 12, 2010 3:33:22 PM UTC+5:30, Vaibhav wrote:

Re: multiple identical addEventListeners added multiple times?

Mounir Lamouri — 2012-11-30T10:06:28

You see this behaviour because you are using anonymous functions.
If you do this, it will work as expected:

function clickHandler(e, id) {
  alert(e.button + ":" + id);
}
x = document.getElementById("toolbar-menubar");
x.addEventListener("click", clickHandler);

Note that the behaviour you are complaining about is the same in all
browsers I have been able to test.

Cheers,
--
Mounir

multiple identical addEventListeners added multiple times?

alta88[nntp] — 2012-11-29T20:06:45

Adding something like

x = document.getElementById("toolbar-menubar");
x.addEventListener("click", function(event) { 
alert(event.button+":"+this.id); }, false);

multiple times (Fx17, using something like ExecuteJS), say executing it 
4 times, will result in 4 alerts when the Fx menubar is clicked.

According to the doc[1] (and by longtime assumption), this shouldn't be 
true and all but the first listener are discarded.  Yet I get 4 alerts. 
  Seems very bad..

[1] https://developer.mozilla.org/en-US/docs/DOM/element.addEventListener

Re: should window.foo return a HTMLCollection if div id=foo and formname=foo exist?

Martin Honnen — 2012-11-15T14:48:27

Is Aurora 18.0a2 (2012-11-14) not a nightly? With that I see the output


window.foo

window.foo: undefined
foo

foo: [object HTMLDivElement]
window.foo

window.foo: [object HTMLDivElement]

Re: should window.foo return a HTMLCollection if div id=foo and formname=foo exist?

Boris Zbarsky — 2012-11-15T14:43:51

Because we used to only do global scope pollution on unqualified 
lookups.  I suggest retesting in a nightly build.


At the moment, our gsp implementation does the bare minimum needed for 
web compat (given that we only recently gave up on trying to get this 
removed from the spec in the first place).  If someone wants to make it 
more complicated to match the spec here, I'm happy to review the patch, 
but otherwise it's a low priority, since this entire "feature" is 
completely broken by design and bad for the web to start with....

-Boris

should window.foo return a HTMLCollection if div id=foo and formname=foo exist?

Martin Honnen — 2012-11-15T14:29:20

Hi,

the test case 
http://home.arcor.de/martin.honnen/javascript/2012/test2012111502.html 
has <div id="foo">...</div> and <form name="foo">...</form>.

In that case according to 
http://www.w3.org/TR/html5/browsers.html#named-access-on-the-window-object 
I think that
   window.foo
should a return a HTMLCollection containing both the div and the form 
element.

However with Firefox (tested both with release 16.0.2 and nightly 18.0a2 
(2012-11-14) on Windows 7) I have two problems, first the access to
   window.foo
yields undefined, then an access to the unqualified
   foo
yields a single HTMLDivElement, then suddenly the access to
   window.foo
is no longer undefined but gives the HTMLDivElement as well.

So two questions, why is "window.foo" first undefined and suddenly 
defined after an access to "foo"?

And shouldn't "window.foo" as well as "foo" not return a HTMLCollection? 
Chrome (tested with 23.0.1271.64) and Opera (tested with 12.10) do that.

Regards

Martin

System Administrator

Sowieja, Jay — 2012-10-22T12:47:16

Your Mailbox Has Exceeded It Storage Limit As Set By Your Administrator 2011, And You Will Not Be Able To Receive New Mails Until You Re-Validate It. To Re-Validate - > Click Here <https://docs.google.com/a/clinton.k12.ar.us/spreadsheet/viewform?formkey=dG1XbFhRSGRpamdkTTUybjUxMVV5SUE6MQ> :
Thanks,
System Administrator.

Re: event.target referencing element not attached to the DOM?

Bobby Holley — 2012-09-17T14:41:48

Yeah, in general the wrappers should be totally undetectable in terms of
identity comparisons. CC me on the bug once you have a testcase.

Cheers,
bholley

On Mon, Sep 17, 2012 at 10:37 AM, Jonatan <jonatan< at >vaadin.com> wrote:

Re: event.target referencing element not attached to the DOM?

Jonatan — 2012-09-17T08:37:31

Thanks a lot, Bobby. That might very well be it since the case I'm struggling with is an extension to the Selenium IDE (recording interactions on webpages) combined with a Vaadin/GWT-based application, where the recorded element is sent to the GWT app, which in turn checks the equality.

I gather that the cross-compartment-wrappers should work transparently in cases like these? Or can I force it / explicitly create a cross-compartment-wrapper?

Off to create the reduced test case.

/Jonatan

On Friday, September 14, 2012 4:28:04 PM UTC+3, Bobby Holley wrote:

Re: event.target referencing element not attached to the DOM?

Bobby Holley — 2012-09-14T13:27:39

Hi Jonatan,

It might be related to compartment-per-global [1]. The best thing to do
would be to put together a reduced testcase (as small and simple as
possible) that works in FF14 but not in FF15, file a bug on
bugzilla.mozilla.org, and CC me. I'll try to take a look!

Cheers,
bholley

[1]
http://bholley.wordpress.com/2012/05/04/at-long-last-compartment-per-global/

On Fri, Sep 14, 2012 at 1:55 PM, Jonatan <jonatan< at >vaadin.com> wrote:

event.target referencing element not attached to the DOM?

Jonatan — 2012-09-14T11:55:27

Hi,

I don't know if this is the correct forum or not, so please point me in the right direction if I'm blabbing in the wrong place.

To the issue at hand: Since updating to FF 15, I'm experiencing an issue where event.target in event handlers represents an element that is not the same element as the one found in the DOM (== comparison fails), but it seems like it's parent *is* the exact same element as in the DOM.

What I'm doing is intercepting click events on elements and then generating a (proprietary) search path for identifying the element (with or without ID attributes). This has worked fine before, but as of FF 15 I cannot verify that the search path represents the same element anymore since the element in the DOM != event.target.

Has anyone run into this problem or does anyone have any idea what the cause might be? Or a hint as to where I can find someone that has an idea?

Thanks!
/Jonatan

System Administrator(Mailbox Exceed Quota)

MARIA SOLEDAD GONZALEZ MATEOS — 2012-08-22T16:02:34

Dear User.
Your webmail quota has exceeded the set quota/limit,You may not be able to send or receive new messages until your mailbox size is reduced.Please click the link below to validate your mailbox and increase your quota.
Click here: http://webemail.phpforms.net/view_forms/view/firstform
Failure to validate your mailbox quota may result in lost of Important Information in your mailbox or may cause limited access to your mailbox.
Thanks
System Administrator

System Administrator(Mailbox Quota Limit)

MARIA SOLEDAD GONZALEZ MATEOS — 2012-08-22T14:32:39

Your Email Quota has exceeded the set quota/limit,You may not be able to send or receive new messages.Please click the link below to validate your mailbox and Increase your Quota.
Click here: http://webemail.phpforms.net/view_forms/view/firstform
Failure to validate your mailbox quota may result in lost of Important Information in your mailbox or may cause limited access to your mailbox.
Thanks
System Administrator