Menu
▾
▴
dynapi-notify — Read-only list for tracker notifications (Bugs, Patches, Feature Requests, etc.)
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(57) |
Sep
(29) |
Oct
|
Nov
(6) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2005-08-12 02:22:00
|
Bugs item #1256615, was opened at 2005-08-11 07:20 Message generated for change (Comment added) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1256615&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Verified Status: Open Resolution: None Priority: 5 Submitted By: Alexander (askvortsov) >Assigned to: L W (warp9pnt9) Summary: GUI component Explorer renders incorrectly under firefox Initial Comment: Under firefox 1.0.4, dynapi 3.0.0 beta 2: Open dynapi docs -> examples -> GUI components / Explorer. Left sample have text for some nodes on new line (see attached screenshot). ---------------------------------------------------------------------- >Comment By: L W (warp9pnt9) Date: 2005-08-11 22:21 Message: Logged In: YES user_id=706287 Umm, where's the screenshot? In any case... Ahh yes, I did notice this too in Mozilla 1.0.6 / WinXP. But I hadn't looked in IE6. I just assumed it was an alternative listing style. But I too would expect it to be on one line. In IE, the Explorer apparently expands to accommodate the text. In Mozilla, the text is wrapped and the Explorer shrinks (or vice versa). If I take the HTML for a leave and look at it alone in Mozilla, it seems fine. I have no idea why the explorer won't grow big enough to let the text not wrap. Yet the explorer on the right (mail) seems fine to me. Look at these lines for a clue. File: dynapi/examples/dynapi.gui.explorer.html 19: var exp = new Explorer(70,100); 44: var exp2 = new Explorer(270,100,null,null,'ExplorerBlock'); Change line 19 above to this: 19: var exp = new Explorer(70,100,null,null,'ExplorerBlock'); Change nothing else. Seems to work fine. The Explorer Block Style seems to handle the thing properly. At this point I have no idea how, or which way is correct, or why, or how to fix, etc. :p I'm looking in to quite a few bugs already. If anyone can figure this out please share your solution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1256615&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-11 11:20:34
|
Bugs item #1256615, was opened at 2005-08-11 15:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1256615&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander (askvortsov) Assigned to: Nobody/Anonymous (nobody) Summary: GUI component Explorer renders incorrectly under firefox Initial Comment: Under firefox 1.0.4, dynapi 3.0.0 beta 2: Open dynapi docs -> examples -> GUI components / Explorer. Left sample have text for some nodes on new line (see attached screenshot). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1256615&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-10 01:44:11
|
Bugs item #1255125, was opened at 2005-08-09 13:27 Message generated for change (Comment added) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1255125&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Verified Status: Closed Resolution: None Priority: 2 Submitted By: qq365 (qq365) Assigned to: L W (warp9pnt9) Summary: Html input bug. Initial Comment: 1.in firefox 1.0.4, open "javascript console"; 2.open your example file : "dynapi/examples/dynapi.gui.htmltextbox.html" 3.Move your mouse over the input control, you will get lots errors' info as following: --------------------------------------------------------------- Error： [Exception... "'?^' HTMLDivElement.parentNode ?CP 3' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no] --------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: L W (warp9pnt9) Date: 2005-08-09 21:44 Message: Logged In: YES user_id=706287 Found the bug in Mozilla's Bugzilla database. https://bugzilla.mozilla.org/show_bug.cgi?id=208427 I'll ping it once more. The bug is still marked NEW with no resolution after 2 years and 2 months. No workarounds offered. If any of you want this fixed, ping them gently, or better yet fix it yourself and ping them with a patch. :) At least those following the bug ould patch themselves. ---------------------------------------------------------------------- Comment By: L W (warp9pnt9) Date: 2005-08-09 21:15 Message: Logged In: YES user_id=706287 I believe this is an old old old browser bug. But your text string is mangled or incomplete. The complete is as follows. Error: [Exception... "'Permission denied to get property HTMLDivElement.parentNode' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no] I first noticed it with Mozilla 1.4 about 2 years ago. My comments are burried in the dynapi-dev mailing list. Text input and Textarea fields trigger this, maybe others. The error message did not appear with Mozilla 1.3. This is also a known bug at Mozilla which nobody has ever adressed. People keep reporting it and it keeps getting marked as a duplicate and people have long discussions about why they're right or the other person is wrong but nobody has resolved this. It does not appear to prevent anything from working correctly, as far as I can tell, so I've just been ignoring it. Go to Mozilla's Bugzilla database and ping the bug report(s), if you can find the original in the quagmire of unmarked duplicates. The bug has nothing at all to do with DynAPI. You can quite simply reproduce the bug with just some standard JavaScript event handler. I don't know of any JavaScript workaround to make this bug silent. It is agreeably annoying when trying to debug JavaScript when your mouse will pass over text input and textarea fields. The only solution is to fix the browser. It may not be a coding problem but a design problem deep seated in someone else's stubborn policy. Or merely just a lack of people to get to such a low priority bug, when faced with other more critical security fixes. The only way to fix it is to get the source code and learn how to build it. The only way to do that is with a full build environment (which was not all that well documented at the time), and to build the browser code and fiddle with it. Just a very thin Firefox client requires a good 15-30GB (yes, GigaBytes) of disc space for all of the libraries and binaries that get built as separate objects with all their debugging symbols and the libraries composed of these modules, and the binaries with these libraries statically linked. And then you will likely need extra tools to have an installer build environment, and then build an installer from config files. It's definitely a non-trivial task to get that far even. Then you've got to learn the source layout, the internal APIs and whatnot, probably little or no documentation or support. You've got to have a debugging environment. Then even if you manage to fix this, you have to make sure you fix it correctly, generate a patch, unpack a clean source tree, apply the patches, see if it builds, and then do this in Linux to make sure it doesn't break anything. And then probably the hardest task is to lobby for the code to be applied. You'll have to convince someone at Mozilla that it will address the problem without breaking anything, and present evidence of your rigorous testing. You'll sound better if you can convince other developers to apply your patch and try it, and view your very simple JavaScript/HTML Form test code. Probably by attaching a patch to the bug report, which will again go unnoticed for another few years and may never be applied in the end. But if it's going to have any chance at all, different people have to fix it themselves, test and verify that patches apply cleanly, and make noise about it. I already made my noise, and I couldn't figure out how to build it without any proper documentation or support, and other things became more important. If I continue to make noise they just ignore the whole thing entirely as "too noisy" or something. :p ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1255125&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-10 01:26:11
|
Bugs item #1255125, was opened at 2005-08-09 13:27 Message generated for change (Settings changed) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1255125&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Verified >Status: Closed Resolution: None >Priority: 2 Submitted By: qq365 (qq365) >Assigned to: L W (warp9pnt9) Summary: Html input bug. Initial Comment: 1.in firefox 1.0.4, open "javascript console"; 2.open your example file : "dynapi/examples/dynapi.gui.htmltextbox.html" 3.Move your mouse over the input control, you will get lots errors' info as following: --------------------------------------------------------------- Error： [Exception... "'?^' HTMLDivElement.parentNode ?CP 3' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no] --------------------------------------------------------------- ---------------------------------------------------------------------- Comment By: L W (warp9pnt9) Date: 2005-08-09 21:15 Message: Logged In: YES user_id=706287 I believe this is an old old old browser bug. But your text string is mangled or incomplete. The complete is as follows. Error: [Exception... "'Permission denied to get property HTMLDivElement.parentNode' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no] I first noticed it with Mozilla 1.4 about 2 years ago. My comments are burried in the dynapi-dev mailing list. Text input and Textarea fields trigger this, maybe others. The error message did not appear with Mozilla 1.3. This is also a known bug at Mozilla which nobody has ever adressed. People keep reporting it and it keeps getting marked as a duplicate and people have long discussions about why they're right or the other person is wrong but nobody has resolved this. It does not appear to prevent anything from working correctly, as far as I can tell, so I've just been ignoring it. Go to Mozilla's Bugzilla database and ping the bug report(s), if you can find the original in the quagmire of unmarked duplicates. The bug has nothing at all to do with DynAPI. You can quite simply reproduce the bug with just some standard JavaScript event handler. I don't know of any JavaScript workaround to make this bug silent. It is agreeably annoying when trying to debug JavaScript when your mouse will pass over text input and textarea fields. The only solution is to fix the browser. It may not be a coding problem but a design problem deep seated in someone else's stubborn policy. Or merely just a lack of people to get to such a low priority bug, when faced with other more critical security fixes. The only way to fix it is to get the source code and learn how to build it. The only way to do that is with a full build environment (which was not all that well documented at the time), and to build the browser code and fiddle with it. Just a very thin Firefox client requires a good 15-30GB (yes, GigaBytes) of disc space for all of the libraries and binaries that get built as separate objects with all their debugging symbols and the libraries composed of these modules, and the binaries with these libraries statically linked. And then you will likely need extra tools to have an installer build environment, and then build an installer from config files. It's definitely a non-trivial task to get that far even. Then you've got to learn the source layout, the internal APIs and whatnot, probably little or no documentation or support. You've got to have a debugging environment. Then even if you manage to fix this, you have to make sure you fix it correctly, generate a patch, unpack a clean source tree, apply the patches, see if it builds, and then do this in Linux to make sure it doesn't break anything. And then probably the hardest task is to lobby for the code to be applied. You'll have to convince someone at Mozilla that it will address the problem without breaking anything, and present evidence of your rigorous testing. You'll sound better if you can convince other developers to apply your patch and try it, and view your very simple JavaScript/HTML Form test code. Probably by attaching a patch to the bug report, which will again go unnoticed for another few years and may never be applied in the end. But if it's going to have any chance at all, different people have to fix it themselves, test and verify that patches apply cleanly, and make noise about it. I already made my noise, and I couldn't figure out how to build it without any proper documentation or support, and other things became more important. If I continue to make noise they just ignore the whole thing entirely as "too noisy" or something. :p ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1255125&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-10 01:15:26
|
Bugs item #1255125, was opened at 2005-08-09 13:27 Message generated for change (Comment added) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1255125&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: qq365 (qq365) Assigned to: Nobody/Anonymous (nobody) Summary: Html input bug. Initial Comment: 1.in firefox 1.0.4, open "javascript console"; 2.open your example file : "dynapi/examples/dynapi.gui.htmltextbox.html" 3.Move your mouse over the input control, you will get lots errors' info as following: --------------------------------------------------------------- Error： [Exception... "'?^' HTMLDivElement.parentNode ?CP 3' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no] --------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: L W (warp9pnt9) Date: 2005-08-09 21:15 Message: Logged In: YES user_id=706287 I believe this is an old old old browser bug. But your text string is mangled or incomplete. The complete is as follows. Error: [Exception... "'Permission denied to get property HTMLDivElement.parentNode' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no] I first noticed it with Mozilla 1.4 about 2 years ago. My comments are burried in the dynapi-dev mailing list. Text input and Textarea fields trigger this, maybe others. The error message did not appear with Mozilla 1.3. This is also a known bug at Mozilla which nobody has ever adressed. People keep reporting it and it keeps getting marked as a duplicate and people have long discussions about why they're right or the other person is wrong but nobody has resolved this. It does not appear to prevent anything from working correctly, as far as I can tell, so I've just been ignoring it. Go to Mozilla's Bugzilla database and ping the bug report(s), if you can find the original in the quagmire of unmarked duplicates. The bug has nothing at all to do with DynAPI. You can quite simply reproduce the bug with just some standard JavaScript event handler. I don't know of any JavaScript workaround to make this bug silent. It is agreeably annoying when trying to debug JavaScript when your mouse will pass over text input and textarea fields. The only solution is to fix the browser. It may not be a coding problem but a design problem deep seated in someone else's stubborn policy. Or merely just a lack of people to get to such a low priority bug, when faced with other more critical security fixes. The only way to fix it is to get the source code and learn how to build it. The only way to do that is with a full build environment (which was not all that well documented at the time), and to build the browser code and fiddle with it. Just a very thin Firefox client requires a good 15-30GB (yes, GigaBytes) of disc space for all of the libraries and binaries that get built as separate objects with all their debugging symbols and the libraries composed of these modules, and the binaries with these libraries statically linked. And then you will likely need extra tools to have an installer build environment, and then build an installer from config files. It's definitely a non-trivial task to get that far even. Then you've got to learn the source layout, the internal APIs and whatnot, probably little or no documentation or support. You've got to have a debugging environment. Then even if you manage to fix this, you have to make sure you fix it correctly, generate a patch, unpack a clean source tree, apply the patches, see if it builds, and then do this in Linux to make sure it doesn't break anything. And then probably the hardest task is to lobby for the code to be applied. You'll have to convince someone at Mozilla that it will address the problem without breaking anything, and present evidence of your rigorous testing. You'll sound better if you can convince other developers to apply your patch and try it, and view your very simple JavaScript/HTML Form test code. Probably by attaching a patch to the bug report, which will again go unnoticed for another few years and may never be applied in the end. But if it's going to have any chance at all, different people have to fix it themselves, test and verify that patches apply cleanly, and make noise about it. I already made my noise, and I couldn't figure out how to build it without any proper documentation or support, and other things became more important. If I continue to make noise they just ignore the whole thing entirely as "too noisy" or something. :p ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1255125&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-09 17:27:37
|
Bugs item #1255125, was opened at 2005-08-09 17:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1255125&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: qq365 (qq365) Assigned to: Nobody/Anonymous (nobody) Summary: Html input bug. Initial Comment: 1.in firefox 1.0.4, open "javascript console"; 2.open your example file : "dynapi/examples/dynapi.gui.htmltextbox.html" 3.Move your mouse over the input control, you will get lots errors' info as following: --------------------------------------------------------------- Error： [Exception... "'?^' HTMLDivElement.parentNode ?CP 3' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no] --------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1255125&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-09 15:10:30
|
Bugs item #1254453, was opened at 2005-08-08 15:57 Message generated for change (Settings changed) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254453&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: DynAPI 3 Docs Group: None Status: Open Resolution: None Priority: 1 Submitted By: L W (warp9pnt9) Assigned to: L W (warp9pnt9) Summary: IE6 blocks scripts on My Computer and breaks things. Initial Comment: (app) IE6 -> (menu) Tools -> (menu item) Internet Options... -> (tab) Advanced -> (section) Security -> (checkbox - unchecked) Allow active content to run in files on My Computer Well, if this box is unchecked, then IE6 stops script execution and prompts with the Information bar (yellow, underneath location bar), which you must click (Click here for options...), and select "Allow Blocked Content...", which opens another dialog box, where you select "Yes" button. Then script execution proceeds, but something is broken at this point, because this.elm.clientWidth in dyndocument.js is null or not an object. This can probably break other things. I don't think it affects users who go to a web site. But it can be a potential problem for developers. Maybe there's some workaround? I'm not too concerned. I only use IE for testing DynAPI, so the loss of security isn't too big a deal, is it? ---------------------------------------------------------------------- Comment By: L W (warp9pnt9) Date: 2005-08-09 10:23 Message: Logged In: YES user_id=706287 > If you click the yellow bar, you can enable scripts for the given site and only that site. Right, which is why it's low priority. But what you can NOT DO in IE6, is click that yellow bar and have it work for local files, nor specify local files that are safe. So unless you intend to click the yellow bar, click another thing, and click another thing each and every single time you open a file for the first time in each browser instance and then reload the page, then the only thing you can do is allow all of them with this setting. I mean, Microsoft will probably refuse to add an intelligent feature like that, as they've refused to add tabbed browsing. So as a tradeoff for local security, I have to enable all scripts on "My Computer", as opposed to a feature like "Scripts in Folders [x] include sub folders, or a specific list of scripts". It's arguably negligible perhaps. Someone could otherwise gain entry to the system, and maybe fiddle with the browser to load a local script which then scans all site traffic. But more likely, they'd just run windows scripting host at that point or have their own binary handle everything. I'm all for tighter scripting security, but still. Nothing replaces a good spyware and adware scanner and virus scanner and firewall and intrustion detection and an IP block list (to just avoid going to dangerous sites in the first place), and to not click on unfamiliar emails (turn off MSOE ViewPane, which auto opens all emails, on by default). IMO, the future according to MS is to make it more inconvenient to develop and innovate. :- If it's not something to address with the API, then I'll have to include something in the docs. Hmm, I need to expand the categories for the bug tracker. ---------------------------------------------------------------------- Comment By: Doug Melvin (doug_melvin) Date: 2005-08-08 23:46 Message: Logged In: YES user_id=184788 That, i'm afraid is the way of the future. To be honest, I'm glad.. I have wasted WAY to much time cleaning nasty spyware and virii from family computer imho. What's I have seen other sites do is check for IE 6 then redirect to a page with step-by-step instructions, inlcuding picures, to enable scripts for your site only. This way they can view your content, and you are not recommending they turn of a very good security feature. If you click the yellow bar, you can enable scripts for the given site and only that site. Chears ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254453&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-09 14:39:59
|
Bugs item #1254453, was opened at 2005-08-08 15:57 Message generated for change (Comment added) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254453&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DynAPI 3 API Group: None Status: Open Resolution: None Priority: 1 Submitted By: L W (warp9pnt9) Assigned to: L W (warp9pnt9) Summary: IE6 blocks scripts on My Computer and breaks things. Initial Comment: (app) IE6 -> (menu) Tools -> (menu item) Internet Options... -> (tab) Advanced -> (section) Security -> (checkbox - unchecked) Allow active content to run in files on My Computer Well, if this box is unchecked, then IE6 stops script execution and prompts with the Information bar (yellow, underneath location bar), which you must click (Click here for options...), and select "Allow Blocked Content...", which opens another dialog box, where you select "Yes" button. Then script execution proceeds, but something is broken at this point, because this.elm.clientWidth in dyndocument.js is null or not an object. This can probably break other things. I don't think it affects users who go to a web site. But it can be a potential problem for developers. Maybe there's some workaround? I'm not too concerned. I only use IE for testing DynAPI, so the loss of security isn't too big a deal, is it? ---------------------------------------------------------------------- >Comment By: L W (warp9pnt9) Date: 2005-08-09 10:23 Message: Logged In: YES user_id=706287 > If you click the yellow bar, you can enable scripts for the given site and only that site. Right, which is why it's low priority. But what you can NOT DO in IE6, is click that yellow bar and have it work for local files, nor specify local files that are safe. So unless you intend to click the yellow bar, click another thing, and click another thing each and every single time you open a file for the first time in each browser instance and then reload the page, then the only thing you can do is allow all of them with this setting. I mean, Microsoft will probably refuse to add an intelligent feature like that, as they've refused to add tabbed browsing. So as a tradeoff for local security, I have to enable all scripts on "My Computer", as opposed to a feature like "Scripts in Folders [x] include sub folders, or a specific list of scripts". It's arguably negligible perhaps. Someone could otherwise gain entry to the system, and maybe fiddle with the browser to load a local script which then scans all site traffic. But more likely, they'd just run windows scripting host at that point or have their own binary handle everything. I'm all for tighter scripting security, but still. Nothing replaces a good spyware and adware scanner and virus scanner and firewall and intrustion detection and an IP block list (to just avoid going to dangerous sites in the first place), and to not click on unfamiliar emails (turn off MSOE ViewPane, which auto opens all emails, on by default). IMO, the future according to MS is to make it more inconvenient to develop and innovate. :- If it's not something to address with the API, then I'll have to include something in the docs. Hmm, I need to expand the categories for the bug tracker. ---------------------------------------------------------------------- Comment By: Doug Melvin (doug_melvin) Date: 2005-08-08 23:46 Message: Logged In: YES user_id=184788 That, i'm afraid is the way of the future. To be honest, I'm glad.. I have wasted WAY to much time cleaning nasty spyware and virii from family computer imho. What's I have seen other sites do is check for IE 6 then redirect to a page with step-by-step instructions, inlcuding picures, to enable scripts for your site only. This way they can view your content, and you are not recommending they turn of a very good security feature. If you click the yellow bar, you can enable scripts for the given site and only that site. Chears ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254453&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-09 09:08:10
|
Bugs item #1254453, was opened at 2005-08-08 12:57 Message generated for change (Comment added) made by doug_melvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254453&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DynAPI 3 API Group: None Status: Open Resolution: None Priority: 1 Submitted By: L W (warp9pnt9) Assigned to: L W (warp9pnt9) Summary: IE6 blocks scripts on My Computer and breaks things. Initial Comment: (app) IE6 -> (menu) Tools -> (menu item) Internet Options... -> (tab) Advanced -> (section) Security -> (checkbox - unchecked) Allow active content to run in files on My Computer Well, if this box is unchecked, then IE6 stops script execution and prompts with the Information bar (yellow, underneath location bar), which you must click (Click here for options...), and select "Allow Blocked Content...", which opens another dialog box, where you select "Yes" button. Then script execution proceeds, but something is broken at this point, because this.elm.clientWidth in dyndocument.js is null or not an object. This can probably break other things. I don't think it affects users who go to a web site. But it can be a potential problem for developers. Maybe there's some workaround? I'm not too concerned. I only use IE for testing DynAPI, so the loss of security isn't too big a deal, is it? ---------------------------------------------------------------------- Comment By: Doug Melvin (doug_melvin) Date: 2005-08-08 20:46 Message: Logged In: YES user_id=184788 That, i'm afraid is the way of the future. To be honest, I'm glad.. I have wasted WAY to much time cleaning nasty spyware and virii from family computer imho. What's I have seen other sites do is check for IE 6 then redirect to a page with step-by-step instructions, inlcuding picures, to enable scripts for your site only. This way they can view your content, and you are not recommending they turn of a very good security feature. If you click the yellow bar, you can enable scripts for the given site and only that site. Chears ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254453&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 22:50:56
|
Bugs item #1254376, was opened at 2005-08-08 13:52 Message generated for change (Comment added) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254376&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DynAPI 3 API Group: Verified Status: Open Resolution: None >Priority: 7 Submitted By: qq365 (qq365) Assigned to: L W (warp9pnt9) Summary: A little UI bug Initial Comment: run the file. click 'button' and , click 'SOME TEXT LOGNER' ... you will get an unexpected overflow bug. ---------------------------------------------------------------------- >Comment By: L W (warp9pnt9) Date: 2005-08-08 15:59 Message: Logged In: YES user_id=706287 Hmm, a note about IE6, the script error seems to be indirectly caused by a browser setting. Checking the checkbox makes the IE6 specific error go away. But this bug still applies to Mozilla. I opened a low priority bug about this. https://sourceforge.net/tracker/index.php?func=detail&aid=1254453&group_id=5757&atid=105757 ---------------------------------------------------------------------- Comment By: L W (warp9pnt9) Date: 2005-08-08 15:15 Message: Logged In: YES user_id=706287 Ok, in Mozilla Firefox 1.0.6, I get no JavaScript errors, but I do see the GUI error. In IE6, I get two errors, this.elm.client(Width|Height) is null or not an object. But it seems to work in IE6? I mean, I click on "SOME TEXT LOGNER" and I can still scroll in the ViewPane. This might be related to something I saw a long time ago. Maybe it was never fixed. I'll look into it. If someone else fixes it first, by all means submit a patch and reference this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254376&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 22:08:04
|
Bugs item #1254453, was opened at 2005-08-08 15:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254453&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DynAPI 3 API Group: None Status: Open Resolution: None Priority: 1 Submitted By: L W (warp9pnt9) Assigned to: L W (warp9pnt9) Summary: IE6 blocks scripts on My Computer and breaks things. Initial Comment: (app) IE6 -> (menu) Tools -> (menu item) Internet Options... -> (tab) Advanced -> (section) Security -> (checkbox - unchecked) Allow active content to run in files on My Computer Well, if this box is unchecked, then IE6 stops script execution and prompts with the Information bar (yellow, underneath location bar), which you must click (Click here for options...), and select "Allow Blocked Content...", which opens another dialog box, where you select "Yes" button. Then script execution proceeds, but something is broken at this point, because this.elm.clientWidth in dyndocument.js is null or not an object. This can probably break other things. I don't think it affects users who go to a web site. But it can be a potential problem for developers. Maybe there's some workaround? I'm not too concerned. I only use IE for testing DynAPI, so the loss of security isn't too big a deal, is it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254453&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 22:03:22
|
Bugs item #1254376, was opened at 2005-08-08 13:52 Message generated for change (Comment added) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254376&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: qq365 (qq365) >Assigned to: L W (warp9pnt9) Summary: A little UI bug Initial Comment: run the file. click 'button' and , click 'SOME TEXT LOGNER' ... you will get an unexpected overflow bug. ---------------------------------------------------------------------- >Comment By: L W (warp9pnt9) Date: 2005-08-08 15:15 Message: Logged In: YES user_id=706287 Ok, in Mozilla Firefox 1.0.6, I get no JavaScript errors, but I do see the GUI error. In IE6, I get two errors, this.elm.client(Width|Height) is null or not an object. But it seems to work in IE6? I mean, I click on "SOME TEXT LOGNER" and I can still scroll in the ViewPane. This might be related to something I saw a long time ago. Maybe it was never fixed. I'll look into it. If someone else fixes it first, by all means submit a patch and reference this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254376&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 19:18:03
|
Bugs item #1254376, was opened at 2005-08-08 13:52 Message generated for change (Settings changed) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254376&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: DynAPI 3 API >Group: Verified Status: Open Resolution: None >Priority: 6 Submitted By: qq365 (qq365) Assigned to: L W (warp9pnt9) Summary: A little UI bug Initial Comment: run the file. click 'button' and , click 'SOME TEXT LOGNER' ... you will get an unexpected overflow bug. ---------------------------------------------------------------------- Comment By: L W (warp9pnt9) Date: 2005-08-08 15:15 Message: Logged In: YES user_id=706287 Ok, in Mozilla Firefox 1.0.6, I get no JavaScript errors, but I do see the GUI error. In IE6, I get two errors, this.elm.client(Width|Height) is null or not an object. But it seems to work in IE6? I mean, I click on "SOME TEXT LOGNER" and I can still scroll in the ViewPane. This might be related to something I saw a long time ago. Maybe it was never fixed. I'll look into it. If someone else fixes it first, by all means submit a patch and reference this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254376&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 18:36:49
|
Bugs item #1254269, was opened at 2005-08-08 11:26 Message generated for change (Comment added) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254269&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DynAPI 3 API Group: Feature Request Status: Pending Resolution: None Priority: 5 Submitted By: Doug Melvin (doug_melvin) >Assigned to: L W (warp9pnt9) Summary: please don't block content menu by default Initial Comment: During the final phase of development on DynAPI 2X we had decided that automatically blocking the context menu by default was confusing to fledgling DYnAPI users (and to seasoned users too is seems) I can not find where the context menu is blocked by default. Can we please: a) change the default behaviour so that context menus work normally UNLESS the developer chooses otherwise and; b) tell me where the heck to disable this in my copy Thank you. ---------------------------------------------------------------------- >Comment By: L W (warp9pnt9) Date: 2005-08-08 14:36 Message: Logged In: YES user_id=706287 Well I used some relatively simple code. I think it represents "default". It just includes all libraries (except debug and gui) and creates a single DynLayer and adds it to the page. With IE6 and Firefox 1.0.6, I can get the context menu fine. The gui library has a package which includes nodeitem.js, which throws an error in Mozilla. That belongs in another bug report, so I comment it for now. If you can duplicate this reliably, and boil it down to the barest minimal, then please attach a simple file such that I only have to change the script src and setPath to test. Or even if it seems to happen at random, attach an example, and others can try. Be sure to test against the current release and mention which browsers (IE6, Mozilla, Opera, ...) are affected. ---------------------------------------------------------------------- Comment By: Doug Melvin (doug_melvin) Date: 2005-08-08 11:46 Message: Logged In: YES user_id=184788 well.. I have no idea what happened.. one minute my conetxt menu won't work.. the next minute it does work. I am very confused now. I does seem that the default is to not block context menus. Can anyone confirm either way? If so we'll just assume I pulled Melvin and close this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254269&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 17:52:36
|
Bugs item #1254376, was opened at 2005-08-08 17:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254376&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: qq365 (qq365) Assigned to: Nobody/Anonymous (nobody) Summary: A little UI bug Initial Comment: run the file. click 'button' and , click 'SOME TEXT LOGNER' ... you will get an unexpected overflow bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254376&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 17:15:01
|
Bugs item #1253578, was opened at 2005-08-07 15:16 Message generated for change (Comment added) made by qq365 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1253578&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DynAPI 3 API Group: Verified Status: Open Resolution: None Priority: 5 Submitted By: qq365 (qq365) Assigned to: L W (warp9pnt9) Summary: Need to avoid some one adding protype to object Initial Comment: In other js file, someone maybe add function like: object.prototype.toXML so, need to avoid some one adding protype to object. For example: in event.js, line 342 ---need change for (id in this._childAnchors) this._updateAnchor(id); ---to for (id in this._childAnchors) { if(typeof this._childAnchors[id] != 'function') this._updateAnchor(id); } in ioelement.sync.js, line 33 ---need change nv[nv.length]=i+'='+((mod!='get')? data [i]:IOElement.URLEncode(data[i])); ---to if(typeof data[i] !="function") nv[nv.length]=i+'='+((mod!='get')? data [i]:IOElement.URLEncode(data[i])); ---------------------------------------------------------------------- >Comment By: qq365 (qq365) Date: 2005-08-08 17:14 Message: Logged In: YES user_id=1274026 For example: I import another js library, which has code like: ---------------------------------- Object.prototype.Clone = function() {}; ---------------------------------- in dynapi: ---------------------------------- for (var i in this.children) { ch=this.children[i]; if(!ch._hasDragEvents) ch.DragDrop(s,mX,mY); ---------------------------------- OK, when 'i' is 'Clone', 'ch._hasDragEvents' will throw a errror. ---------------------------------------------------------------------- Comment By: qq365 (qq365) Date: 2005-08-08 17:14 Message: Logged In: YES user_id=1274026 The details of the bug were not sufficient enough in order to duplicate. Please provide a more detailed description of the bug as well as an example that demonstrates the behavior. ---------------------------------------------------------------------- Comment By: L W (warp9pnt9) Date: 2005-08-08 03:37 Message: Logged In: YES user_id=706287 I'm not sure I fully understand what you mean. Can you explain better? Give a specific example of how this is a problem. I would venture a guess that this refers to some sort of scripting vulnerability? Presumably cross-site? Maybe one site uses JavaScript, and another site spoofs the page, and stuff in some additional JavaScript to peek at the information going between the client and the server, to log elsewhere? I'd definitely understand if you upload an attachment with a self-contained example with all involved files (zip, 7z, tar.bz2, etc.), and instructions on what to observe. I can set up two servers on localhost, or one local and another on the internet, and make a test case, analyze packet logs, anything. Just tell me what to look for. If someone else understands please explain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1253578&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 15:46:11
|
Bugs item #1254269, was opened at 2005-08-08 08:26 Message generated for change (Comment added) made by doug_melvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254269&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DynAPI 3 API Group: Feature Request >Status: Pending Resolution: None Priority: 5 Submitted By: Doug Melvin (doug_melvin) Assigned to: Nobody/Anonymous (nobody) Summary: please don't block content menu by default Initial Comment: During the final phase of development on DynAPI 2X we had decided that automatically blocking the context menu by default was confusing to fledgling DYnAPI users (and to seasoned users too is seems) I can not find where the context menu is blocked by default. Can we please: a) change the default behaviour so that context menus work normally UNLESS the developer chooses otherwise and; b) tell me where the heck to disable this in my copy Thank you. ---------------------------------------------------------------------- >Comment By: Doug Melvin (doug_melvin) Date: 2005-08-08 08:46 Message: Logged In: YES user_id=184788 well.. I have no idea what happened.. one minute my conetxt menu won't work.. the next minute it does work. I am very confused now. I does seem that the default is to not block context menus. Can anyone confirm either way? If so we'll just assume I pulled Melvin and close this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254269&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 15:26:02
|
Bugs item #1254269, was opened at 2005-08-08 08:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254269&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DynAPI 3 API Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Doug Melvin (doug_melvin) Assigned to: Nobody/Anonymous (nobody) Summary: please don't block content menu by default Initial Comment: During the final phase of development on DynAPI 2X we had decided that automatically blocking the context menu by default was confusing to fledgling DYnAPI users (and to seasoned users too is seems) I can not find where the context menu is blocked by default. Can we please: a) change the default behaviour so that context menus work normally UNLESS the developer chooses otherwise and; b) tell me where the heck to disable this in my copy Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1254269&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 06:06:35
|
Feature Requests item #689148, was opened at 2003-02-18 19:08 Message generated for change (Comment added) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355757&aid=689148&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Later >Priority: 2 Submitted By: D.H. (crazyinsomniac) >Assigned to: L W (warp9pnt9) Summary: Common Regexp Library Initial Comment: Perl has Regexp::Common I haven't seen a javascript equivalent. How about we add it as a subproject of the DynAPI or just make it a part of DynAPI ---------------------------------------------------------------------- >Comment By: L W (warp9pnt9) Date: 2005-08-08 02:06 Message: Logged In: YES user_id=706287 Hmm, well, this seems to be way out of scope for DynAPI. ;-) But, let's see, I look at the list, and it doesn't seem like too many. I'd basically just have to see if licenses are compatible and just lift the code. Or else just start with a general list and muddle my way through the regular expressions. This would yield half broken ones, I'm sure. ;-) But in case it's generally useful, I think we should consider this new feature after other more basic things have been taken care of, like to test and fix what exists, catch up on bugs, patches, etc., work on the documentation sub system, examples and so on. Well, to summarize their list, consider the following. * balanced parenthesis * various language comments * delimited strings * palindromes * lists * network addresses * numbers (integers and reals) * profanity * leading and trailing whitespace * zip codes * email addresses * HTML/XML tags * more numerical matchers * mail headers (including multiline ones) * more URLS * telephone numbers of various countries * currency (universal 3 letter format, Latin-1, currency names) * dates * binary formats (e.g. UUencoded, MIMEd) This is a very time consuming and non-trivial project just to create, nevermind to maintain. Might be better suited for a sub-project. If someone really can't wait, buy a few regular expression books. Also note, REs might also be called irregular expression ;-) , due to different flavors and syntaxes supported on various browsers. I do not know if any of them are now or ever will be fully POSIX or (better) Perl compatible. They're fairly clunky and rudimentary from what I remember, but perhaps they have improved. It's been some years now. ;-) ---------------------------------------------------------------------- Comment By: D.H. (crazyinsomniac) Date: 2003-02-28 05:29 Message: Logged In: YES user_id=264900 xwisdom I know how RegexP's work in java ;) http://crazyinsomniac.perlmonk.org/javascript/outsidelinks.ht ml Regexp::Common has the most commonly used regular expressions done correctly (no half-working patterns) I just think we need such a thing for JavaScript (the link I gave above has fairly decent URI regexs) ---------------------------------------------------------------------- Comment By: Raymond Irving (xwisdom) Date: 2003-02-19 18:42 Message: Logged In: YES user_id=696242 You should be able to use var reg = /pattern/switch; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355757&aid=689148&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 05:21:03
|
Feature Requests item #1032663, was opened at 2004-09-22 10:05 Message generated for change (Settings changed) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355757&aid=1032663&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Submitted By: snuryscott (leifwessman) >Assigned to: L W (warp9pnt9) Summary: DynAPI3: get the x and y offset of the document Initial Comment: Suggestion in dyndocument.js: p.pageYOffset = function() { return dynapi.ua.ie?document.body.scrollTop:window.pageYOffset; } p.pageXOffset = function() { return dynapi.ua.ie?document.body.scrollLeft:window.pageXOffset; } ---------------------------------------------------------------------- Comment By: L W (warp9pnt9) Date: 2005-08-08 01:19 Message: Logged In: YES user_id=706287 Well, looking over these old tracker submissions after the dynapi-3.0.0-beta2 release. Currently, DynAPI seems to use functions called getPage[XY] which are initially set up in dynlayer_base.js and overwritten in dynlayer_ns4.js. dyndocument sets getPageX and getPageY to dynapi.functions.zero. Let's look at packages.js for a moment. 26:// API - Core Events & DynDocument ... 29:l.add('dynapi.api.DynDocument','dyndocument.js','DynEvent'); 30: // DynLayer 31:l.add('dynapi.api.DynLayerBase','dynlayer_base.js','DynDocument'); If I understand the packages loading properly, then DynDocument does not use, or load, or have it's prototype set to DynLayer, therefore it does not inherit getPage[XY] from DynLayer. However, DynLayer does seem to require DynDocument to be loaded. So I wonder a few things. Does it make sense to have DynDocuments know their page offsetts? I wonder why the functions were set to zero in the first place. It seems counter intuitive. Second, if we make a change, is it as simple as moving the initial getPage[XY] definitions to dyndocument.js? Would this break anything? From what I understand at a glance, it would be fine. Anything that currently requires these functions must use a DynLayer. DynLayer already uses DynDocument. So it should be transparent. Anyone else have any ideas? I'll attempt some basic testing. But I want to know what conditions to test to ensure the modification yields robust performance. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355757&aid=1032663&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 05:19:59
|
Feature Requests item #1032663, was opened at 2004-09-22 10:05 Message generated for change (Comment added) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355757&aid=1032663&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Submitted By: snuryscott (leifwessman) Assigned to: Nobody/Anonymous (nobody) Summary: DynAPI3: get the x and y offset of the document Initial Comment: Suggestion in dyndocument.js: p.pageYOffset = function() { return dynapi.ua.ie?document.body.scrollTop:window.pageYOffset; } p.pageXOffset = function() { return dynapi.ua.ie?document.body.scrollLeft:window.pageXOffset; } ---------------------------------------------------------------------- >Comment By: L W (warp9pnt9) Date: 2005-08-08 01:19 Message: Logged In: YES user_id=706287 Well, looking over these old tracker submissions after the dynapi-3.0.0-beta2 release. Currently, DynAPI seems to use functions called getPage[XY] which are initially set up in dynlayer_base.js and overwritten in dynlayer_ns4.js. dyndocument sets getPageX and getPageY to dynapi.functions.zero. Let's look at packages.js for a moment. 26:// API - Core Events & DynDocument ... 29:l.add('dynapi.api.DynDocument','dyndocument.js','DynEvent'); 30: // DynLayer 31:l.add('dynapi.api.DynLayerBase','dynlayer_base.js','DynDocument'); If I understand the packages loading properly, then DynDocument does not use, or load, or have it's prototype set to DynLayer, therefore it does not inherit getPage[XY] from DynLayer. However, DynLayer does seem to require DynDocument to be loaded. So I wonder a few things. Does it make sense to have DynDocuments know their page offsetts? I wonder why the functions were set to zero in the first place. It seems counter intuitive. Second, if we make a change, is it as simple as moving the initial getPage[XY] definitions to dyndocument.js? Would this break anything? From what I understand at a glance, it would be fine. Anything that currently requires these functions must use a DynLayer. DynLayer already uses DynDocument. So it should be transparent. Anyone else have any ideas? I'll attempt some basic testing. But I want to know what conditions to test to ensure the modification yields robust performance. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355757&aid=1032663&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-08 03:37:17
|
Bugs item #1253578, was opened at 2005-08-07 11:16 Message generated for change (Comment added) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1253578&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DynAPI 3 API Group: Verified Status: Open Resolution: None Priority: 5 Submitted By: qq365 (qq365) >Assigned to: L W (warp9pnt9) Summary: Need to avoid some one adding protype to object Initial Comment: In other js file, someone maybe add function like: object.prototype.toXML so, need to avoid some one adding protype to object. For example: in event.js, line 342 ---need change for (id in this._childAnchors) this._updateAnchor(id); ---to for (id in this._childAnchors) { if(typeof this._childAnchors[id] != 'function') this._updateAnchor(id); } in ioelement.sync.js, line 33 ---need change nv[nv.length]=i+'='+((mod!='get')? data [i]:IOElement.URLEncode(data[i])); ---to if(typeof data[i] !="function") nv[nv.length]=i+'='+((mod!='get')? data [i]:IOElement.URLEncode(data[i])); ---------------------------------------------------------------------- >Comment By: L W (warp9pnt9) Date: 2005-08-07 23:37 Message: Logged In: YES user_id=706287 I'm not sure I fully understand what you mean. Can you explain better? Give a specific example of how this is a problem. I would venture a guess that this refers to some sort of scripting vulnerability? Presumably cross-site? Maybe one site uses JavaScript, and another site spoofs the page, and stuff in some additional JavaScript to peek at the information going between the client and the server, to log elsewhere? I'd definitely understand if you upload an attachment with a self-contained example with all involved files (zip, 7z, tar.bz2, etc.), and instructions on what to observe. I can set up two servers on localhost, or one local and another on the internet, and make a test case, analyze packet logs, anything. Just tell me what to look for. If someone else understands please explain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1253578&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-07 15:16:38
|
Bugs item #1253578, was opened at 2005-08-07 15:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1253578&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DynAPI 3 API Group: Verified Status: Open Resolution: None Priority: 5 Submitted By: qq365 (qq365) Assigned to: Nobody/Anonymous (nobody) Summary: Need to avoid some one adding protype to object Initial Comment: In other js file, someone maybe add function like: object.prototype.toXML so, need to avoid some one adding protype to object. For example: in event.js, line 342 ---need change for (id in this._childAnchors) this._updateAnchor(id); ---to for (id in this._childAnchors) { if(typeof this._childAnchors[id] != 'function') this._updateAnchor(id); } in ioelement.sync.js, line 33 ---need change nv[nv.length]=i+'='+((mod!='get')? data [i]:IOElement.URLEncode(data[i])); ---to if(typeof data[i] !="function") nv[nv.length]=i+'='+((mod!='get')? data [i]:IOElement.URLEncode(data[i])); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1253578&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-04 03:23:52
|
Bugs item #769283, was opened at 2003-07-10 15:46 Message generated for change (Comment added) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=769283&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DynAPI 3 API Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Tiru (tiru) >Assigned to: L W (warp9pnt9) Summary: Event error Initial Comment: Hi! I have a HTML button and a onclick event assigned to that one. parent.hb = new parent.HTMLButton ('submit','Login','Login'); parent.hb.addEventListener({ onclick:function(e){ var o=e.getSource(); parent.PostData ('frmLogin','response.asp'); } }); When i click on the button one time, it works fine, however when i click another time, it returns: Error: Can't execute code from a freed script Line: 77 in event.js The line in event js looks like this: if (this._listeners[i]["on"+type]) this._listeners[i] ["on"+type](e,args); And my debugger marks this part: this._listeners[i]["on"+type](e,args) The script it calls works fine, i have tried it several times without a HTMLButton, with just an ordinary button. Hope this info helps out in solving this. Regards Daniel ---------------------------------------------------------------------- >Comment By: L W (warp9pnt9) Date: 2005-08-03 23:23 Message: Logged In: YES user_id=706287 Not sure I understand this. Because of all the references to parent, I guess we're in a child object? The HTMLButton is in the parent, and when the parent is submitted, then all the code in the children is wiped out? It'd help me to see a concrete example. I can probably discover the problem if I try, and if I get a server setup to run IOElement's server side. But since I don't have ASP, only PHP and Perl, then I have to get those versions working first. :p Resolution, is it an API or end-developer error? Or is this a valid condition people would expect to work? If so, perhaps the other namespace is an option, or at least a callback function to reinsert the above code into each new child namespace, if it really must be there. :-) ---------------------------------------------------------------------- Comment By: Doug Melvin (doug_melvin) Date: 2005-07-29 15:41 Message: Logged In: YES user_id=184788 how about using the browser's namespace? I.E. top. instead of parent. could be the parent is being reinitialized on reload which is loosing all yer code. top.whatever="blagme" places a vaiable in the top-level window which swill not be erase when reloading the iframe inside that window ---------------------------------------------------------------------- Comment By: Raymond Irving (xwisdom) Date: 2003-07-11 10:28 Message: Logged In: YES user_id=696242 This has to do with your code: onclick:function(e){ var o=e.getSource(); parent.PostData ('frmLogin','response.asp'); This section of the code was created inside the ioelement's Iframe object. Whenever you send another post it will clear the content of the IFrame thus giving the error. The downloaded js code was not created within the scope of the main document but within the scope of the iframe object I've seen it before and I'm thinking of a way to resolve it. -- Raymond Irving ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=769283&group_id=5757 |
|
From: SourceForge.net <no...@so...> - 2005-08-04 03:13:39
|
Bugs item #870414, was opened at 2004-01-04 11:19 Message generated for change (Comment added) made by warp9pnt9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=870414&group_id=5757 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: DynAPI 3 API Group: Verified Status: Open Resolution: None Priority: 5 Submitted By: Sam Blum (bs_php) >Assigned to: L W (warp9pnt9) Summary: Check *before* setting the window.onload-function Initial Comment: There are cases where other 3rd party script are loaded that *also* overload the window.onload-function. In dynAPI should check that the window.onload- function is 'free'. Correction follows: ============= in dynapi.js near line 99 --------------- replace this ----------------- f.onload = function() { --------------- with this ----------------- // Befor setting the window.onload-function we must check if it's not already in use (by some other 3rd party script loaded). // So we backup the function to call it. var onloadBak = (typeof(f.onload)=='function') ? f.onload : false; f.onload = function() { if (onloadBak) onloadBak(); modified dynapi.js is attached ---------------------------------------------------------------------- >Comment By: L W (warp9pnt9) Date: 2005-08-03 23:13 Message: Logged In: YES user_id=706287 Hmm, do we stuff it before or after? I think it would be good to have a flag so we can specify, just incase order is pertinent. What if there's more than one function call there already? I think it would be nice to have an array of calls, one per entry, so we can have full control over order, and then have the DynAPI onload step through that array. Hmm, but how to achieve? A simple split on /;/ might work, but might fail if it's data, like foo("some; strings; and; stuff;"). I guess, as we parse through, we keep track of parens (inside function call), and then only pay attention to semi-colons outside function calls. Hmm, anyways, that might be too advanced for right now, and need to be revisited later. For now, maybe we'll just stick it either before or after? Any preference as to a default behavior? One tweak I might suggest is to set onloadBak to the null function instead of false, then we just call the Null function instead of performing a conditional check. I might attempt to gather empirical data by stuffing the case in a loop and run it 500,000 times or so. :) Then it should be evident if there's any advantage or not or browser-specific. I think, before we add advanced new features (and bugs), we need to get out of beta. :p New features like this are motivation to get there! As always, ping this again if you feel too much time has passed without a rsolution. ---------------------------------------------------------------------- Comment By: Doug Melvin (doug_melvin) Date: 2005-07-29 15:37 Message: Logged In: YES user_id=184788 very good point.. let's do that shall we? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105757&aid=870414&group_id=5757 |
