ItayOW

OW API bug report / change request /missing documentation

Recommended Posts

Hey all, 

Please help us improve our API!
If you've found a bug, think that we need to change something, have comments regrading our documentation or have special requests, we want to know about that.

Please fill the following fields with the relevant data so we can understand better what needs to be fixed/changed:

  • Reported date:

  • Reported by:

  • Contact mail:

  • OW version: (how to find my OW version)

  • App name:

  • App version:(how to know your app version)

  • Summary:

  • Bug/Change request description

    • How to reproduce / what change is requested (if needed add here code segments)  

    • Steps to reproduce:

      1. ...

  • Expected Results:

  • Actual Results:

  • Add info

    • Logs

    • Screenshots



Thanks for your support!

Share this post


Link to post
Share on other sites

Ok, let's try this:

  • Reported date: 07.09.2016

  • Reported by: Colorfustan

  • Contact mail: overwolf-forum@krispin.it

  • OW version: 0.97.209

  • App name: Legendary Builds

  • App version:(how to know your app version)

  • Summary:
    Css-rule negative z-index prevents dragMove triggering

  • Bug/Change request description

    • How to reproduce / what change is requested (if needed add here code segments)  

      I have an angular directive on a div that contains all of my dynamically loaded content

    • <div id="content" ow-drag-move>
      	<div ui-view></div>
      </div>
      // ow-drag-move directive
      link: function (scope, element, attr) {
        element.on('mousedown', function (event) {
          owWindows.gettingCurrentWindowName()
              .then(owWindows.dragMove);
           }
      }

      works for every element that gets inserted into the div#content without any troubles, but if an Element gets a negative z-index css rule, the mousedown event does not propagate to the surrounding div (and might even not get triggered for the element itself, did not test that).
      No problem when using positive z-index values

    • Steps to reproduce:

      1. install the demo-app

      2. add dragmove function as event-handler for mousedown on a surrounding element

      3. give a child-element z-index: -1

  • Expected Results: Element should still be able to receive events and propagate them through the DOM hierarchy

  • Actual Results: see above

  • Add info

Share this post


Link to post
Share on other sites

An easy one:

 

  • Reported date: 09/07/16

  • Reported by: goodbyte

  • OW version: 0.97.304.0

  • Summary: SMITE - The event data returned from onNewEvents is not a valid JSON string.

  • Expected Results: {"playername":"Deadguy","killername":"yourname"}

  • Actual Results: playername:Deadguy,killername:yourname

Share this post


Link to post
Share on other sites
On 9/7/2016 at 7:48 PM, Colorfulstan said:

Ok, let's try this:

  • Reported date: 07.09.2016

  • Reported by: Colorfustan

  • Contact mail: overwolf-forum@krispin.it

  • OW version: 0.97.209

  • App name: Legendary Builds

  • App version:(how to know your app version)

  • Summary:
    Css-rule negative z-index prevents dragMove triggering

  • Bug/Change request description

    • How to reproduce / what change is requested (if needed add here code segments)  

      I have an angular directive on a div that contains all of my dynamically loaded content

    • 
      <div id="content" ow-drag-move>
      	<div ui-view></div>
      </div>
      
      // ow-drag-move directive
      link: function (scope, element, attr) {
        element.on('mousedown', function (event) {
          owWindows.gettingCurrentWindowName()
              .then(owWindows.dragMove);
           }
      }

      works for every element that gets inserted into the div#content without any troubles, but if an Element gets a negative z-index css rule, the mousedown event does not propagate to the surrounding div (and might even not get triggered for the element itself, did not test that).
      No problem when using positive z-index values

    • Steps to reproduce:

      1. install the demo-app

      2. add dragmove function as event-handler for mousedown on a surrounding element

      3. give a child-element z-index: -1

  • Expected Results: Element should still be able to receive events and propagate them through the DOM hierarchy

  • Actual Results: see above

  • Add info

Thanks!
Bug was opened, I will update you when it's fixed.

Share this post


Link to post
Share on other sites
  • Report date: 2016-09-11
  • OW version: 0.97.304.0

All apps are rendered at the incorrect size on high density displays.

I use a 2560x1600 monitor rendering at dimensions of 1280x800. The system reports the actual screen size but Windows apps use the screen density to determine the "actual" resolution of the display. For instance, my monitor is rendering at 200%, so 10px from the left of the screen should actually be 20 physical pixels.

This results in the Overwolf store being 2x larger than it should be (making it impossible to use.) As well, when working in dev mode, `screen.height` reports 1600 which is correct, but `window.devicePixelRatio` reports 1, which is incorrect - it should be 2. Addressing the root cause will fix this problem I believe.

Right now this is of course causing my app to be rendered at the incorrect size, and trying to position my app window relative to the bottom right of the screen causes the app to be rendered entirely off screen (because the Chrome internals aren't rendering at native resolution.) Here's a screenshot. Notice how the Overwolf browser window is rendering at the correct resolution, but the browser content is rendering at half resolution. b2OE3Dl.png

Share this post


Link to post
Share on other sites
On 9/8/2016 at 2:21 AM, goodbyte said:

An easy one:

 

  • Reported date: 09/07/16

  • Reported by: goodbyte

  • OW version: 0.97.304.0

  • Summary: SMITE - The event data returned from onNewEvents is not a valid JSON string.

  • Expected Results: {"playername":"Deadguy","killername":"yourname"}

  • Actual Results: playername:Deadguy,killername:yourname

Thanks,

We need to talk to Smite developers to see if it's possible...
We will update you when we know anything new.

Share this post


Link to post
Share on other sites
14 hours ago, lwansbrough said:
  • Report date: 2016-09-11
  • OW version: 0.97.304.0

All apps are rendered at the incorrect size on high density displays.

I use a 2560x1600 monitor rendering at dimensions of 1280x800. The system reports the actual screen size but Windows apps use the screen density to determine the "actual" resolution of the display. For instance, my monitor is rendering at 200%, so 10px from the left of the screen should actually be 20 physical pixels.

This results in the Overwolf store being 2x larger than it should be (making it impossible to use.) As well, when working in dev mode, `screen.height` reports 1600 which is correct, but `window.devicePixelRatio` reports 1, which is incorrect - it should be 2. Addressing the root cause will fix this problem I believe.

Right now this is of course causing my app to be rendered at the incorrect size, and trying to position my app window relative to the bottom right of the screen causes the app to be rendered entirely off screen (because the Chrome internals aren't rendering at native resolution.) Here's a screenshot. Notice how the Overwolf browser window is rendering at the correct resolution, but the browser content is rendering at half resolution. b2OE3Dl.png

Thank you!

Bug was opened.

Share this post


Link to post
Share on other sites
  • Reported date: 09/12/16 ( Question, do we have to post the date in retard or non retard mode? I've seen some incongruences between posts )

  • Reported by: goodbyte

  • OW version: 0.97.304.0

  • Summary: CS:GO - mvp, team_set and spectating events are not listed in the documentation.

 

Share this post


Link to post
Share on other sites
43 minutes ago, goodbyte said:
  • Reported date: 09/12/16 ( Question, do we have to post the date in retard or non retard mode? I've seen some incongruences between posts )

  • Reported by: goodbyte

  • OW version: 0.97.304.0

  • Summary: CS:GO - mvp, team_set and spectating events are not listed in the documentation.

 

There are a few bugs in these events (related to Valve GSI), that's the reason we don't list them...

Share this post


Link to post
Share on other sites
  • Reported date: 19.09.2016

  • Reported by: Colorfulstan

  • OW version: 0.97.306

  • Summary:
    overwolf.games.getRunningGameInfo breaks when switching between multiple games

  • Bug/Change request description

    • Steps to reproduce:

      1. open league of legends match

      2. overwolf.games.getRunningGameInfo() now will return the information for league of legends

      3. open another game

      4. overwolf.games.getRunningGameInfo() now will return the information for the second game started, regardless which game has the focus. Additionally, 

      5. close the other game

      6. overwolf.games.getRunningGameInfo() now will return null

  • Expected Results:
    overwolf.games.getRunningGameInfo should return the correct information.
    Even better would be an option to get the information for all running games.

logs.rar

Edited by Colorfulstan

Share this post


Link to post
Share on other sites
16 hours ago, Colorfulstan said:
  • Reported date: 19.09.2016

  • Reported by: Colorfulstan

  • OW version: 0.97.306

  • Summary:
    overwolf.games.getRunningGameInfo breaks when switching between multiple games

  • Bug/Change request description

    • Steps to reproduce:

      1. open league of legends match

      2. overwolf.games.getRunningGameInfo() now will return the information for league of legends

      3. open another game

      4. overwolf.games.getRunningGameInfo() now will return the information for the second game started, regardless which game has the focus. Additionally, 

      5. close the other game

      6. overwolf.games.getRunningGameInfo() now will return null

  • Expected Results:
    overwolf.games.getRunningGameInfo should return the correct information.
    Even better would be an option to get the information for all running games.

logs.rar

Bug was opened, thanks!

Share this post


Link to post
Share on other sites
  • Reported date: 20.09.2016

  • Reported by: BobDev

  • OW version: 0.97.306

  • Summary:
    overwolf.windows.changePosition sets incorrect values if you call it when window is minimized while in game

  • Bug/Change request description

    • Steps to reproduce:

      1. open any game for example Hearthstone in windowed mode

      2. resize the window using drag to make it smaller

      3. Open attached demo app

      4. Second window should be on bottom right of the screen 

  • Expected Results:
    Second window is positioned above system clock, instead it is somewhere in the middle of the screen.
    If you run changePosition while the window is visible the call will work and the window will be correctly placed.
    My resolution is
    2560x1080 but I think it behaves the same no matter what you set.

MinimizedWindowSetPositionBug.7z

Edited by BobDev

Share this post


Link to post
Share on other sites
  • Reported date: 20.09.2016

  • Reported by: BobDev

  • OW version: 0.97.306

  • Summary:
    overwolf.windows.dragMove breaks after you open your desktop only app and a game

  • Bug/Change request description

    • Steps to reproduce:

      1. Open attached demo app

      2. While no game is opened try to drag the window

      3. Open ?Hearthstone or other game in windowed mode and try to drag

  • Expected Results:
    Drag works no matter what, instead drag works as long as you wont open any game, once you open a game drag breaks. When you close the game drag will start to work again.

DesktopOnlyWhileInGameBreaksDragBug.7z

Edited by BobDev

Share this post


Link to post
Share on other sites
13 hours ago, BobDev said:
  • Reported date: 20.09.2016

  • Reported by: BobDev

  • OW version: 0.97.306

  • Summary:
    overwolf.windows.changePosition sets incorrect values if you call it when window is minimized while in game

  • Bug/Change request description

    • Steps to reproduce:

      1. open any game for example Hearthstone in windowed mode

      2. resize the window using drag to make it smaller

      3. Open attached demo app

      4. Second window should be on bottom right of the screen 

  • Expected Results:
    Second window is positioned above system clock, instead it is somewhere in the middle of the screen.
    If you run changePosition while the window is visible the call will work and the window will be correctly placed.
    My resolution is
    2560x1080 but I think it behaves the same no matter what you set.

MinimizedWindowSetPositionBug.7z

Bug was opened.

Share this post


Link to post
Share on other sites
13 hours ago, BobDev said:
  • Reported date: 20.09.2016

  • Reported by: BobDev

  • OW version: 0.97.306

  • Summary:
    overwolf.windows.dragMove breaks after you open your desktop only app and a game

  • Bug/Change request description

    • Steps to reproduce:

      1. Open attached demo app

      2. While no game is opened try to drag the window

      3. Open ?Hearthstone or other game in windowed mode and try to drag

  • Expected Results:
    Drag works no matter what, instead drag works as long as you wont open any game, once you open a game drag breaks. When you close the game drag will start to work again.

DesktopOnlyWhileInGameBreaksDragBug.7z

Bug was opened, thanks!

Share this post


Link to post
Share on other sites

Propably not really an Issue for anyone, but just noticed this one:

 

  • Reported date: 21.09.2016

  • Reported by: Colorfulstan

  • OW version: 0.97.306

  • Summary: inconsistent callback argument on overwolf.windows.getWindowState(windowId, callback) compared to other .windows. callback arguments  

  • Expected Results:

    overwolf.windows.getWindowState('nonexistingWindow', console.log.bind(console))
    // output: Object {status: "error", error: "Window with id:'nonexistingWindow' does not exist"}

     

  • Actual Results:

    overwolf.windows.getWindowState('nonexistingWindow', console.log.bind(console))
    // output: Object {status: "success", window_id: "nonexistingWindow", window_state: "closed"}

Share this post


Link to post
Share on other sites

Another convenience / consistency thing regarding overwolf.windows

  • Reported date: 21.09.2016

  • Reported by: Colorfulstan

  • OW version: 0.97.306

  • Summary: overwolf.windows.restore() can not be used with a window name

  • Expected Results:
    overwolf.windows.restore() should be consistent with the other overwolf.windows methods in that it can be used with a window Id and a window name

 

  • Actual Results:
overwolf.windows.restore('WindowName', console.log.bind(console))
// Output: Object {status: "error", error: "no window with the given id was found."}

 

EDIT: it works with the name when the window is minimized, but to open it up when it was closed you need to wrap it the overwolf.windows.obtainDeclaredWindow() call and pass it the id.

 

 

 

Edited by Colorfulstan

Share this post


Link to post
Share on other sites
10 hours ago, Colorfulstan said:

Another convenience / consistency thing regarding overwolf.windows

  • Reported date: 21.09.2016

  • Reported by: Colorfulstan

  • OW version: 0.97.306

  • Summary: overwolf.windows.restore() can not be used with a window name

  • Expected Results:
    overwolf.windows.restore() should be consistent with the other overwolf.windows methods in that it can be used with a window Id and a window name

 

  • Actual Results:

overwolf.windows.restore('WindowName', console.log.bind(console))
// Output: Object {status: "error", error: "no window with the given id was found."}

 

EDIT: it works with the name when the window is minimized, but to open it up when it was closed you need to wrap it the overwolf.windows.obtainDeclaredWindow() call and pass it the id.

 

 

 

Thanks, both bugs were opened. 

Share this post


Link to post
Share on other sites
  • Reported date: 04.10.2016

  • Reported by: Colorfulstan

  • OW version:

  • App name: Overwolf Game Event Provider

  • App version: 0.15

  • Summary: overwolf.games.events Documentation for League of Legends needs update and boolean values need to be fixed asap

  1. Description for InfoDB is out of date
  2. Where it says " true/false " for the Information those values are NOT true/false but "True" / "False" (strings) which can not be parsed easily to a boolean in JS:
    "False" == false // false
    "false" == false // false
    JSON.parse("False") == false // Uncaught SyntaxError: Unexpected token F
    JSON.parse("false") == false // true
    JSON.parse("0") == false // true
    
    "True" == true // false
    "true" == true // false
    JSON.parse("True") == true // Uncaught SyntaxError: Unexpected token T
    JSON.parse("true") == true // true
    JSON.parse("1") == true // true

    Currently the only way to get the correct value is:

    JSON.parse("False".toLowerCase()) == false // true
    JSON.parse("True".toLowerCase()) == true // true

    which is pretty annoying and more importantly will break in case there actually would be a boolean value returned. So the only bulletproof workaround is:

    var value = "False" + ""
    JSON.parse(value.toLowerCase()) == false // true
    value = "True" + ""
    JSON.parse(value.toLowerCase()) == false // true

    which is ridiculous for getting a simple value.

  3. Example for team-feature decoding is out of date (it's not an array anymore)

 

Share this post


Link to post
Share on other sites
5 minutes ago, Colorfulstan said:
  • Reported date: 04.10.2016

  • Reported by: Colorfulstan

  • OW version:

  • App name: Overwolf Game Event Provider

  • App version: 0.15

  • Summary: overwolf.games.events Documentation for League of Legends needs update and boolean values need to be fixed asap

  1. Description for InfoDB is out of date
  2. Where it says " true/false " for the Information those values are NOT true/false but "True" / "False" (strings) which can not be parsed easily to a boolean in JS:
    
    "False" == false // false
    "false" == false // false
    JSON.parse("False") == false // Uncaught SyntaxError: Unexpected token F
    JSON.parse("false") == false // true
    JSON.parse("0") == false // true
    
    "True" == true // false
    "true" == true // false
    JSON.parse("True") == true // Uncaught SyntaxError: Unexpected token T
    JSON.parse("true") == true // true
    JSON.parse("1") == true // true

    Currently the only way to get the correct value is:

    
    JSON.parse("False".toLowerCase()) == false // true
    JSON.parse("True".toLowerCase()) == true // true

    which is pretty annoying and more importantly will break in case there actually would be a boolean value returned. So the only bulletproof workaround is:

    
    var value = "False" + ""
    JSON.parse(value.toLowerCase()) == false // true
    value = "True" + ""
    JSON.parse(value.toLowerCase()) == false // true

    which is ridiculous for getting a simple value.

  3. Example for team-feature decoding is out of date (it's not an array anymore)

 

Just FIY this is global overwolf issue most likely caused by c# to string conversion.
Example postMessage between windows

Share this post


Link to post
Share on other sites
4 minutes ago, BobDev said:

Just FIY this is global overwolf issue most likely caused by c# to string conversion.
Example postMessage between windows

Has to be the root I think in C# booleans are True and False so it's not converted to JS compatible values before it gets emitted.

Either has to be changed for everything or at least documentation has to be clear about this, might be the most easy root of very hard to find bugs if your a seasoned JS developer and are expecting a boolean value where it actually gives you a non-empty string, which will always evaluate to true with == and to false with === comparisson

Share this post


Link to post
Share on other sites
  • Reported date: 04.10.2016

  • Reported by: Colorfulstan

  • OW version:

  • App name: Overwolf Game Event Provider

  • App version: 0.15

 

EDIT:

  • Summary: overwolf.games.getInfo() callback argument is inconsistent with the remaining callback arguments

 

Im describing the general basetype for callback Arguments in Typescript as follows:

/** Argument passed to a callback */
interface ODKCallbackArg {
    status: 'success' | 'error'
    /** only available when status === 'error' stating the reason for failure */
    error?: string
}

However, for overwolf.games.getInfo() the typing would look like this:

/** Argument passed to a callback */
interface ODKCallbackArg {
    status: 'status' | 'error'
    /** only available when status === 'error' stating the reason for failure */
    reason?: string
}

I don't know if there are other callbacks that differ from the first, general pattern but I think all callbacks should be consistent across the board, otherwise it makes working with them more of a pain then it should be.

As it is right now it would actually be neccessary to doublecheck every method for success and for error status to be sure in which format it is, the same is true for most of the API-methods in general since documentation often is out of date.

Edited by Colorfulstan

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now