- 当前 Bug 的表现（可附上截图） 有两个接口，第一个10s 超时报错之后，第二个虽然也超出了时间10s，但是照样完成了请求，并成功返回（12s返回）。 容我细细道来 首先，场景是这样的，有两个请求（getProductCnt，isEnroll），在接口请求开始，success，fail与complete均打印出相关信息与时间，另外，networkTimeout的request时间是10s [图片] 1、如下，发起getProductCnt请求，可以看到红框中，请求时间是2018-11-01 16:47:38 [图片] 也可以在这张图看到，这个时间是小程序自己输出的。请求时间是2018-11-01 16:47:38 [图片] 2、如下，发起isEnroll接口请求，可以看到红框中，请求时间也是2018-11-01 16:47:38 [图片] 3、接下来就是响应，首先是getProductCnt请求失败，可以看到，红框中请求失败的时间是2018-11-01 16:47:48，非常标准的符合10s超时,下面也有小程序报出来的超时错误 [图片] 4、最后我们来看下，isEnroll的接口请求，此时可以看到，红框中请求完成的时间是2018-11-01 16:47:50，系统也标出了request success的时间。 问题来了： isEnroll接口从请求开始到请求完成，一共经历了12s，而上一个接口getProductCnt则在10s，就准时报错。 [图片] - 预期表现     请求超时应该都进入fail，报tomeout错误信息。 还有一个疑问，小程序的request原理是怎么样的。会不会有情况是一个接口超时之后，会将超时重置？

- 当前 Bug 的表现（可附上截图） 有两个接口，第一个10s 超时报错之后，第二个虽然也超出了时间10s，但是照样完成了请求，并成功返回（12s返回）。 容我细细道来 首先，场景是这样的，有两个请求（getProductCnt，isEnroll），在接口请求开始，success，fail与complete均打印出相关信息与时间，另外，networkTimeout的request时间是10s [图片] 1、如下，发起getProductCnt请求，可以看到红框中，请求时间是2018-11-01 16:47:38 [图片] 也可以在这张图看到，这个时间是小程序自己输出的。请求时间是2018-11-01 16:47:38 [图片] 2、如下，发起isEnroll接口请求，可以看到红框中，请求时间也是2018-11-01 16:47:38 [图片] 3、接下来就是响应，首先是getProductCnt请求失败，可以看到，红框中请求失败的时间是2018-11-01 16:47:48，非常标准的符合10s超时,下面也有小程序报出来的超时错误 [图片] 4、最后我们来看下，isEnroll的接口请求，此时可以看到，红框中请求完成的时间是2018-11-01 16:47:50，系统也标出了request success的时间。 问题来了： isEnroll接口从请求开始到请求完成，一共经历了12s，而上一个接口getProductCnt则在10s，就准时报错。 [图片] - 预期表现     请求超时应该都进入fail，报tomeout错误信息。 还有一个疑问，小程序的request原理是怎么样的。会不会有情况是一个接口超时之后，会将超时重置？

- 当前 Bug 的表现（可附上截图） 有两个接口，第一个10s 超时报错之后，第二个虽然也超出了时间10s，但是照样完成了请求，并成功返回（12s返回）。 容我细细道来 首先，场景是这样的，有两个请求（getProductCnt，isEnroll），在接口请求开始，success，fail与complete均打印出相关信息与时间，另外，networkTimeout的request时间是10s [图片] 1、如下，发起getProductCnt请求，可以看到红框中，请求时间是2018-11-01 16:47:38 [图片] 也可以在这张图看到，这个时间是小程序自己输出的。请求时间是2018-11-01 16:47:38 [图片] 2、如下，发起isEnroll接口请求，可以看到红框中，请求时间也是2018-11-01 16:47:38 [图片] 3、接下来就是响应，首先是getProductCnt请求失败，可以看到，红框中请求失败的时间是2018-11-01 16:47:48，非常标准的符合10s超时,下面也有小程序报出来的超时错误 [图片] 4、最后我们来看下，isEnroll的接口请求，此时可以看到，红框中请求完成的时间是2018-11-01 16:47:50，系统也标出了request success的时间。 问题来了： isEnroll接口从请求开始到请求完成，一共经历了12s却没有报错，而上一个接口getProductCnt则在10s，就准时报错。 [图片] - 预期表现     请求超时应该都进入fail，报tomeout错误信息。 还有一个疑问，小程序的request原理是怎么样的。会不会有情况是一个接口超时之后，会将超时重置？

相关代码： app.js使用 [代码]wx.showModal({[代码] [代码]    [代码][代码]title: [代码][代码]'更新提示'[代码][代码],[代码] [代码]    [代码][代码]content: [代码][代码]'新版本已经准备好，是否重启应用？'[代码][代码],[代码] [代码]    [代码][代码]success: [代码][代码]function[代码] [代码](res) {[代码] [代码]    [代码][代码]}[代码] [代码]})[代码]        问题机型：         ios手机，安卓机不会         微信版本6.7以上，低版本不会出现             1、在app.js使用showModal 的时候，如果有页面调用wx.redirectTo跳转页面，就会导致模态框闪关，按home键重新打开微信，模态框又会出现~~~         2、使用showModal 的时候，如果其他地方调用了 wx.hideLoading，wx.hideToast，wx.hideNavigationBarLoading（wx.hideNavigationBarLoading使用前要先/wx.showNavigationBarLoading()），就会导致模态框闪关，按home键重新打开微信，模态框又会出现~~~         这两个问题一开始是在线上的onUpdateReady导致的。现在发现，实际原因是showModal 跟redirectTo这几个方法冲突了。         PS: 现在问题2不能重现，问题1就是代码片段中的情况         求解决，我看社区，4月份已经有人提了，这么久都没人理。。。。

- 当前 Bug 的表现（可附上截图）     下图，开卡组件提交之后回调，     appid变了，不是指定的，而是返回了小程序自己的appi     [图片] - 预期表现     [图片] - 提供一个最简复现 Demo     wx.openCard 回调 App.onshow获取的options参数即可查看到

RT ios 通过小程序打开卡券的时候，底部会有“已放入‘我’ - ‘卡包’，点击查看”的链接 [图片] 但是，同样的操作，在安卓机子上，则没有“已放入‘我’ - ‘卡包’，点击查看”的链接，已经滑到最底部了，也没有。 不止一台安卓机。 [图片]

RT，想咨询一下，开卡组件的手机验证码的获取次数，是否有限制（一个用户获取次数）呢？ [图片]

跳转型开卡的跳转链接设置问题 请问， 能否设置跳转到小程序？ 跟这两个参数有关吗wx_activate_after_submit_url 和 activate_app_brand_pass ，能不能提供一个案例呢