Custom Query (18300 matches)


Show under each result:

Results (151 - 153 of 18300)

Ticket Resolution Summary Owner Reporter
#9675 invalid A problem with some UTF8 symbols alex Aleksey Rechinskiy

Hi. I've searched for a special notices about UTF8 support in ShrinkSafe?, but found nothing interesting except that it looks like ShrinkSafe? _should_ support utf8. I wanted to ask about this issue in Dojo forums first, but forums are closed, so, I guess, it will be no harm if I write it here and it will appear it is my mistake.

Ok. I've used files with UTF8 strings for a long time with ShringSafe? (almost a year) and have no problems with them until today with a simple common Russian word 'Это' (this).

Here is the test strings:

var str='Это';
var str_1="Это";
var str2='Ещё кириллица';
var str3='Первая проблема с кириллицей за год';

running ShrinkSafe? (bundled in dojo 1.3.2) on them produces invalid result with the first two strings:

var str="ё‚о";
var str_1="ё‚о";
var str2="Ещё кириллица";
var str3="Первая проблема с кириллицей за год";

Last two strings processed correctly. I've never encountered the problems like this with ShrinkSafe? before...

Here is the hex dump of start of original file:

00000000:  76 61 72 20-73 74 72 3D-27 D0 AD D1-82 D0 BE 27  var str='╨н╤В╨╛'
00000010:  3B 0A 76 61-72 20 73 74-72 5F 31 3D-22 D0 AD D1  ;
var str_1="╨н╤
00000020:  82 D0 BE 22-3B 0A 76 61-72 20 73 74-72 32 3D 27  В╨╛";
var str2='

And shrinksafe'ed file:

00000000:  76 61 72 20-73 74 72 3D-22 D0 D1 82-D0 BE 22 3B  var str="╨╤В╨╛";
00000010:  0A 76 61 72-20 73 74 72-5F 31 3D 22-D0 D1 82 D0  
var str_1="╨╤В╨
00000020:  BE 22 3B 0A-76 61 72 20-73 74 72 32-3D 22 D0 95  ╛";
var str2="╨Х

Here is a command line:

java -jar shrinksafe.jar %THIS_DIR%\shs_test.js > %THIS_DIR%\shs_test.compiled.js

Is it an expected behavior of ShrinkSafe? and I shouldn't use it on UTF8 strings, or it is some sort of a bug?

#11771 duplicate dojox.image.Lightbox::_scaleToFit() work wrong causing invalid image resizing anonymous Aleksey Rechinskiy

Hi All!

I had a problem displaying large panoramic images (with image.width > viewport.width ) and found a bug in a widget's rescale function ( _scaleToFit() ).

If you take a look into _scaleToFit() source code you'll see near the top of the function scaling algorithm:

// one of the dimensions is too big, go with the smaller viewport edge:
if(this._vp.h > this._vp.w){
	// don't actually touch the edges:
	ns.w = this._vp.w - 80;
	ns.h = ns.w * (size.h / size.w);
	// give a little room for the titlenode, too:
	ns.h = this._vp.h - 60 - this._lastTitleSize.h;
	ns.w = ns.h * (size.w / size.h);

Algorithm decides how to rescale image by examining the vieport's size and, obviously, it is bad idea in case of wide panoramic image. Looks like it should do it by examining the image's size, something like this:

var w=size.w, h=size.h;
if(w+100 > this._vp.w){
	// don't actually touch the edges:
	ns.w = this._vp.w - 100;
	ns.h = ns.w * (h / w);
	h=ns.h; w=ns.w;
//its better to check [new] height here because we don't know if it fits into viewport
if (h + 60 + this._lastTitleSize.h > this._vp.h ){
	// give a little room for the titlenode, too:
	ns.h = this._vp.h - 60 - this._lastTitleSize.h;
	ns.w = ns.h * (w / h);

This code works better and rescales images properly. Thanks)

#14381 invalid Switching off "dojo-sync-loader" breaks XHR in compiled builds? Rawld Gill Aleksey Rechinskiy


I tried to build minimalistic dojo-AMD loader and played with 'dojo-sync-loader' option. If one to set in a profile

staticHasFeatures: {

then a big bunch of code in dojo.js starting from line 202 to line 284 is completely eliminated by has("dojo-sync-loader")->0. This code amongst other things defines function require.getXhr() that becomes undefined in that case. Looks like it is the only place in dojo's code, where require.getXhr() is defined.

require.getXhr() function is used in dojo/_base/xhr.js line 15 to define dojo._xhrObj

if(has("dojo-xhr-factory")){ // set to 1 by default build profile.
	dojo._xhrObj = require.getXhr;

And dojo._xhrObj is used later in dojo.xhr() to create XHR transport object.

So, looks like any build with 'dojo-sync-loader' disabled crashes on any attempt to use xhr machinery...

Note: See TracQuery for help on using queries.