美洽怎么设置访客端聊天窗口全屏模式切换?
美洽访客端可以通过控制台直接配置或在前端自定义切换为全屏聊天窗口。通常在控制台的聊天窗口或样式设置里有展示模式选项;若无内建全屏开关,可用前端覆盖样式、切换容器类、禁用页面滚动、处理键盘与触摸事件,以及在不同终端上分别适配,从而实现稳定且用户友好的全屏切换体验。支持日志埋点和无障碍优化可回退到浮窗模式

先把原理讲清楚——什么叫“访客端全屏切换”
简单来说,全屏切换就是把原本以浮窗、小窗或侧边栏形式展示的聊天界面,扩展到覆盖整个浏览器或移动屏幕。看起来像原生页面而不是一个小角落的对话框。要做到这点,基本上有两条路:一是用美洽后台自带的配置(如果有这个选项),二是通过前端主动控制样式和行为,把聊天容器变成全屏并处理交互细节。
为什么要这样分两路思考
- 后台配置:最省心,适合不想动前端代码的产品或业务。
- 前端自定义:最灵活,可以做动画、埋点、无障碍和特殊适配(比如按键或者手势退出)。
第一条路:在美洽控制台找配置(最快的办法)
步骤非常直接,按这个顺序找就不会走弯路:
- 登录美洽管理后台(企业账号)
- 进入「渠道/工作台/网站接入」或「设置」中与聊天窗口相关的配置页(不同版本可能命名略有差异)
- 查找「聊天窗口样式」「展示模式」「窗口样式」之类的选项,如果有“全屏/浮窗/嵌入”等切换,开启或保存配置即可
- 在测试页面刷新并检查访客端是否按预期以全屏方式打开
注意:控制台配置因版本和套餐不同可能存在差异,找不到时就去前端实现那条路。
第二条路:前端自定义实现(通用且可定制)
要点一:定位聊天容器并覆盖样式
美洽通常会在页面中注入一个聊天容器(可能是一个 div 或 iframe),你需要定位到这个容器,然后在其打开时给它加上“全屏类名”。一个典型的做法是给容器添加 mq-fullscreen 这样的类,然后用 CSS 把它撑满屏幕。
示例 CSS(通用思路)
.mq-fullscreen {
position: fixed !important;
top: 0 !important;
left: 0 !important;
width: 100% !important;
height: 100% !important;
right: 0 !important;
bottom: 0 !important;
z-index: 2147483647 !important; /* 保证在最上层 */
border-radius: 0 !important;
box-shadow: none !important;
}
body.mq-no-scroll {
overflow: hidden !important; /* 防止背景滚动 */
}
要点二:如何在脚本里切换这个类(示例代码)
页面中你可能没有立即拿到聊天容器的引用——它是异步注入的。这时用 MutationObserver 或间隔轮询都可以。
/* 简单示例,按需调整选择器 */
function findChatContainer() {
return document.querySelector('.meiqia-widget') || document.getElementById('meiqia_im_container');
}
function enterFullscreen() {
const el = findChatContainer();
if (!el) return;
el.classList.add('mq-fullscreen');
document.body.classList.add('mq-no-scroll');
// 可在此埋点:告知后端用户切换为全屏
}
function exitFullscreen() {
const el = findChatContainer();
if (!el) return;
el.classList.remove('mq-fullscreen');
document.body.classList.remove('mq-no-scroll');
}
/* 监听 ESC 键退出,兼顾无障碍 */
document.addEventListener('keydown', function(e) {
if (e.key === 'Escape') exitFullscreen();
});
要点三:元素还没注入怎么办(MutationObserver)
const observer = new MutationObserver((records, obs) => {
if (findChatContainer()) {
// 容器出现后可绑定事件或调整样式
obs.disconnect();
}
});
observer.observe(document.body, { childList: true, subtree: true });
移动端与 iOS Safari 的坑(以及怎么处理)
- 移动浏览器的 100vh 在 iOS 上会因为地址栏收起而变化,做全屏时优先使用 top/left/bottom/right 固定定位而非单纯依赖 vh。
- 当 body overflow 被设为 hidden 后,有时会影响软键盘弹出的滚动行为,测试输入场景并做适配(必要时只在容器内禁滚动)。
- 微信内置浏览器可能对 iframe 或外部脚本有更严格限制,建议在微信环境下多测试并保留“回退到浮窗”方案。
与 iframe 或第三方注入相关的问题
如果美洽以 iframe 形式注入聊天窗口,直接修改 iframe 内的样式会被同源策略限制。解决方案:
- 如果 iframe 与父页面同源,可通过 iframe.contentDocument 修改样式。
- 如果不同源,优先用 iframe 的外层容器做定位(让外层容器全屏),或在美洽后台/SDK 中寻找内建的全屏参数。
- 必要时联系美洽技术支持索要推荐做法或 SDK 接口。
无障碍与交互细节(别只让它看着全屏)
- 聚焦管理:全屏打开时应该把焦点放到聊天输入框,退出时把焦点返回到用户最后的交互元素。
- 键盘导航:确保 Tab 顺序合理,支持 ESC 退出。
- 屏幕阅读器:为容器增加 role=”dialog” 和 aria-modal=”true” 等属性(如果可控),并在开启/关闭时更新 aria 状态。
埋点与分析建议
全屏是一个极具意义的用户行为,建议记录以下事件:
- 用户点击“进入全屏”的时间点
- 进入全屏后会话是否被发送消息或转人工
- 全屏停留时长与退出时长(用于衡量体验)
- 从全屏直接跳转页面或被外链带走的行为
不同平台的实现对照(方便决策)
| 平台 | 推荐实现路径 | 优缺点 |
| PC 网页 | 优先后台配置;无则前端类名 + CSS 覆盖 | 实现简单、兼容性好;样式要高优先级 |
| 移动网页 | 前端自定义(fixed 定位 + 禁滚动 + 处理软键盘) | 需处理 iOS vh 问题与软键盘交互 |
| 微信/小程序内网页 | 优先后台或 SDK 指定,必要时提供浮窗回退 | 容器注入限制多,测试成本高 |
| 原生 App | 使用美洽 iOS/Android SDK 的界面方法或自定义容器 | 可以实现最顺滑的原生全屏体验,但需走原生代码 |
常见问题与排查清单(遇到问题先看这儿)
- 页面还是能滚动?检查有没有忘记给 body 添加 overflow:hidden,或者某个元素有 touchmove 未被阻止。
- 全屏被其他元素遮挡?提高 z-index 并检查父元素是否有 transform 属性(会创造新的 stacking context)。
- 样式不生效?确认选择器是否正确,或样式是否被 iframe 隔离。
- 软键盘遮挡输入框?把输入框滚动到可视区,或者在打开全屏时设置输入框到靠近屏幕底部的位置。
实操建议(怎么开始,步骤式)
- 先在美洽后台找“展示模式/窗口样式”,如果有开关就用它。
- 没有的话,在开发环境先写一套 mq-fullscreen CSS 并本地覆盖测试。
- 用 MutationObserver 检测美洽容器注入,绑定进入/退出逻辑与埋点。
- 测试桌面、iOS、Android、微信内置浏览器,记录差异并做适配。
- 加上无障碍属性和 ESC 退出,完善用户体验。
写到这儿,我想到一点:如果你是产品经理,先把“是否需要全屏”做决策树(什么时候自动全屏、什么时候手动切换、是否埋点)画出来;如果你是工程师,先做一个小实验页把样式、键盘、滚动、iframe 情况都测一遍,然后再合入线上。顺便记得把回退方案留好,用户体验总是比技术炫酷更重要。