Get your own customer support community

About me

Recent activity

Subscribe to this feed
  • idea

    ungram replied on November 10, 2009 16:02 to the idea "javascript.options.showInConsole" in Mozilla:

    ungram
    Yes, I agree to your guess.
    But that scenario is not unique to Ubiquity. It can be applied to all addons, or all scripts for scriptable addons such as UserChrome.js, and so on -- but I believe they don't set the Pref compulsorily in user's environment.

    What I want to point out is;

    • There is NO choices for users to avoid this behavior.

      Especially, even if user sets to false via about:config, it becomes true again and again on every startup.

      (So I had to patch builtincmds.js and onstartup.js. I'm afraid when Ubiquity is integrated to Firefox...)

    • I believe this Pref (feature) is mainly provided for Developers, for their development/debugging environment.

      (I think that's the reason why Firefox's default is false. Sorry if I'm worng)

    • It's also useful for troubleshooting on user's environment, but the frequency is rare (few percent ?) as compare with general usecases.


    So I feel 'compulsive true (at every startup) on user's environment' is overdoing -- it's just my feeling.

    Then,

    • If enabling this Pref is very useful for not only rare case but also major use, Firefox's default value may be changed to true.

    • If not, "user's choice" should be provided, such as:

      put enable/disable option in Firefox's option dialog or Ubiquity's setup/development page.

      Then the developer will ask user like "Enable this option, then what's in your console?"



    Frankly speeking, I'm not sure the demerit about enabling this Pref... Does message flood occur ? Maybe developers will fix bugs (in their 'log enabling' environment) before the release. How about performance or memory footprint ? I don't know:-P maybe less effect ?

    I'm only anxious, so I cannot request. But I hope Ubiquity team consider about this behavior when integrate to Firefox.
    Do you think this is one of the best points? Mark it as a good point
  • idea

    ungram shared an idea in Mozilla on November 06, 2009 10:53:

    ungram
    javascript.options.showInConsole
    Ubiquity seems to set 'javascript.options.showInConsole' to 'true' compulsorily at every startup (I'm not sure about other logging options). I feel this(these?) Pref should be left as default (false) in general use, to avoid message flood which are usually meaningless for users.
    If it's mainly useful in development phase, I think that puttig such 'toggle' option in Command Editor Page may be better.
  • idea

    ungram shared an idea in Mozilla on October 13, 2009 06:12:

    ungram
    Open Ubiquity window at outside of browser window
    I think it's good to have an 'Option Setting' to open Ubiquity window at outside of browser window.
    Currently Ubiquity window is opened inside browser window and hides a lot of browse area. Opening Ubiquity window on Desktop (outside of browser) makes user to be able to see both Ubiquity window and browse area.
    I think it may be feasible by using openPopupAtScreen() instead of openPopup() in Ubiquity.openWindow() method (but I don't know well about XUL...). I usually patch ubiquity.js like above and have no trouble; Ubiquity works fine with outer-window.
    # I'm Windows user so I'm not sure whether it works on other platform.
  • problem

    ungram replied on September 15, 2009 04:24 to the problem "No unicode support in jQuery(?)" in Mozilla:

    ungram
    I think it's depends on what char-code the Web server requires, especially for non-ascii chars.
    The web page given above (http://jesms.no/privat/minside/) seems written in ISO-8859-1 (including FORM element), so I guess the server may require ISO-8859-1 encoded string as POST data. If so, you have to transcode the string to that charcode (and URL-escape it). I hope Utils.convertFromUnicode() helps it.

    If the server implements auto-charcode-detection and internal-charcode-transcoding, such server will provide multiple charcode I/F, so it will accept UTF-8 data even if it's web page (and FORM) is written in localized charcode.
    If the server accepts UTF-8, I guess both satyr's way and following will work:
    var data = "...&sms_message=" + encodeURIComponent(non_ascii_char);
    Do you think this solves the problem? Mark it as solved
  • problem

    A comment on the problem "Date.toLocaleString() returns broken Kanji when called in preview()" in Mozilla:

    ungram
    Thanks a lot. I'll write private date-formatter to work around. – ungram, on September 13, 2009 13:13
  • star

    ungram marked one of satyr's replies in Mozilla as useful. satyr replied to the problem "Date.toLocaleString() returns broken Kanji when called in preview()".

  • problem

    ungram reported a problem in Mozilla on September 12, 2009 03:31:

    ungram
    Date.toLocaleString() returns broken Kanji when called in preview()
    WinXP+SP3(Japanese), Firefox:(JP)3.5.2/.3, Ubiq:0.5.4

    In Japanese environment, Date.toLocaleString() returns Kanji-mixed string.
    But when it's called in command's preview() function, or called for object-property's initialization, it returns 'broken' (unreadable) Kanji-chars.
    String.charCodeAt() seems that it generates Shift-JIS encoded Kanji-chars, not Unicode.
    In contrast, it returns correct Kanji-mixed string when called in command's execute() function (and of course it's okay when running on browser, as normal web script).
    I also tried to replace scripts/date.js with Datejs ja-JP version (packed in Datejs-all-Alpha1.zip), then restarted Firefox, but nothing changed.
    I'm not sure whether this behavior can be reproduced in other user's environment. Is it Ubiquity's defect, or is my environment's problem ?

    CmdUtils.CreateCommand({
    names: ["test"],
    str: (new Date()).toLocaleString(), //NG:Kanji broken
    preview: function(pblock) {
    displayMessage( (new Date()).toLocaleString() ); //NG:Kanji broken
    },
    execute: function() {
    displayMessage( (new Date()).toLocaleString() ); //OK:correct Kanji
    }
    });