منع تكرار التبويبات بعد انهيار المتصفح: خوارزمية مصالحة بين الحالة المحفوظة والنوافذ الحية

العودة إلى الصفحة ليست المشكلة الوحيدة

قد يستعيد المتصفح عشر تبويبات بعد انهيار مفاجئ، ثم يضيف عشرًا أخرى لأن عامل الاستعادة أعاد تشغيل نفسه أو لأن نافذة كانت مفتوحة بالفعل قبل قراءة السجل. المستخدم يرى صفحات مكررة، وقد تعيد بعض الصفحات إرسال طلبات أو تشغيل صوت أو استهلاك موارد. هذا الدليل لا يشرح فقط كيفية تفعيل Session Restore؛ بل يركز على منع ازدواجية الإنشاء عندما تتسابق عمليتان أو تتأخر كتابة سجل الجلسة. الحل يبدأ بتعريف هوية منطقية لكل تبويب ومصالحة الحالة المرغوبة مع النوافذ الحية قبل أي عملية فتح.

عرّف ما الذي تريد استعادته

ليست كل تبويبات المتصفح متساوية: هناك تبويب عادي يمكن إعادة فتح رابطه، ونموذج لم يُحفظ، ونافذة خاصة، وصفحة داخلية، وتبويب صوت أو تنزيل نشط. حدّد السياسة لكل نوع قبل البرمجة. قد يكون استرجاع الرابط آمنًا، لكن إعادة تنفيذ POST أو إعادة تشغيل مهمة آلية دون موافقة قد تكرر أثرًا خارجيًا. افصل بين استعادة واجهة العرض واستعادة حالة التطبيق واستعادة الأعمال الجارية. لا تعد المستخدم بأن كل حالة ستعود كما كانت؛ وثّق بوضوح ما يمكن حفظه وما لا يمكن استعادته لأسباب تقنية أو خصوصية.

لماذا لا يكفي URL كمفتاح إزالة تكرار؟

قد يفتح المستخدم الرابط نفسه في تبويبين عمدًا للمقارنة، وقد يحتوي الرابط على معلمات مختلفة تمثل حالة مفيدة، وقد تتغير أجزاء منه بعد التنقل. إزالة كل URL مكرر ستفقد تبويبات مشروعة. أنشئ tabInstanceId ثابتًا خلال دورة حياة التبويب، و windowInstanceId للنافذة، ومعرف بروفايل مستقل، ثم اربط سجل الاستعادة بهذه المعرفات. لا تستخدم عنوان الصفحة أو وقت الفتح وحدهما كمفتاح؛ فكلاهما قد يتغير أو يتكرر. عند فقد المعرف بعد عطل قد تحتاج قواعد مصالحة احتياطية معلنة بدل حذف عشوائي.

احفظ Snapshot ومعه سجل أحداث قصير

يمكن تخزين لقطة دورية للحالة مع سجل أحداث من نوع tabOpened و tabMoved و tabClosed و windowClosed، بحيث يعاد بناء الحالة إلى آخر نقطة سليمة. أضف رقم جيل أو revision متزايدًا، واكتب الملفات بطريقة ذرية أو داخل معاملة مدعومة حسب التخزين المستخدم. لا تفترض أن وصول إشعار نجاح الكتابة يضمن الحماية من كل انقطاع كهرباء؛ تختلف ضمانات التخزين. احتفظ ببصمة للتحقق من سلامة الملف، ونسخة احتياطية حديثة عند الحاجة. إذا تعارضت لقطة مع سجل غير مكتمل، اتبع قاعدة استعادة موثقة بدل جمع الاثنين بلا تمييز.

امنع عاملين من استعادة الحالة نفسها

قد يبدأ عامل الاستعادة مرتين بسبب إعادة إطلاق التطبيق أو مؤقت متداخل. استخدم قفلًا أو Lease مناسبًا مع معرف جيل، واجعل كل عملية فتح قابلة للتكرار دون إنشاء نسخة ثانية عند إعادة المحاولة. قبل فتح تبويب تحقق من وجود tabInstanceId بالفعل في سجل التبويبات الحية، ثم أعد الفحص عند تنفيذ الفتح إذا كان هناك تزامن. لا تعتمد على فحص ثم إنشاء منفصلين دون حماية من السباق. إذا فقد العامل القفل أثناء التنفيذ، يجب أن يتوقف عن التعديلات الجديدة بدل الاستمرار باعتباره المالك الوحيد.

مصالحة الحالة المرغوبة مع الحالة الفعلية

ابنِ مجموعتين: desiredTabs من آخر حالة سليمة، و liveTabs من النوافذ الموجودة الآن. قارنهما بمفتاح profileId و windowInstanceId و tabInstanceId، لا بمحتوى URL فقط. احتفظ بالتبويبات الحية المطابقة، وأنشئ الناقصة فقط، ولا تغلق الزائدة تلقائيًا إلا إذا كانت السياسة واضحة والمستخدم لن يفقد عملًا. قد تكون هناك نافذة افتتحها المستخدم بعد بدء الاستعادة؛ تعامل معها كحدث جديد لا كتلوث. سجّل قرار كل تبويب: reused أو created أو skipped أو needsReview، ليصبح التشخيص قابلًا للتدقيق.

أعد بناء الترتيب دون تغيير الهوية

بعد معرفة التبويبات التي ستبقى، أعد ترتيبها وفق مواضعها المحفوظة دون إعادة إنشائها. تعامل مع التبويبات المثبتة والمجموعات والنوافذ المنبثقة كأنواع مستقلة إذا كان التطبيق يدعمها. لا تفتح كل الروابط بالتوازي لمجرد اختصار الزمن؛ يمكن أن يؤدي ذلك إلى ضغط ذاكرة أو انهيار ثانٍ. ابدأ بنافذة واحدة وتدرج في التحميل مع الحفاظ على إمكانية إلغاء الاستعادة. إذا فشل تبويب واحد، لا تعد العملية كلها من البداية وتضاعف البقية؛ سجّل فشله واستأنف منه فقط.

كيف تتعامل مع إغلاق متزامن أثناء الانهيار؟

قد يغلق المستخدم تبويبًا قبل العطل مباشرة، لكن حدث الإغلاق لم يصل إلى التخزين، فتظهر الصفحة مجددًا بعد الاستعادة. يمكن تقليل ذلك بتسجيل Tombstone أو حدث إغلاق ذي revision قبل حذف السجل القديم، مع فهم حدود الكتابة عند انقطاع مفاجئ. لا تجعل Tombstone أبديًا؛ ضع سياسة تنظيف بعد حفظ Snapshot مؤكد. اختبر أيضًا حالة إغلاق نافذة كاملة وفتح أخرى بالعنوان نفسه. إذا كانت الأدلة غير كافية لتحديد قصد المستخدم، اعرض جلسة قابلة للاستعادة يدويًا بدل فتح كل شيء بصورة قسرية.

اختبر سيناريوهات السباق لا سيناريو واحدًا

أنشئ بروفايل اختبار يحوي تبويبين بالرابط نفسه عمدًا وتبويبًا آخر مختلفًا، ثم احفظ الحالة. جرّب إنهاء العملية أثناء كتابة Snapshot، وبعد حفظه، وأثناء إنشاء أول تبويب مستعاد، وبعد فتح نافذة ثانية. أعد تشغيل التطبيق مرتين بسرعة في بيئة آمنة واختبر عدم ظهور نسخ إضافية. لا تستخدم بيانات مستخدمين أو نماذج حقيقية. كرر كل حالة عدة مرات لأن سباقات التوقيت قد لا تظهر في التشغيل الأول. سجّل عدد التبويبات قبل الانهيار وبعده ومعرفاتها وليس مجرد لقطة شاشة.

مصفوفة قبول واضحة

يُعد الاختبار ناجحًا عندما تعود التبويبات ذات المعرفات المحفوظة مرة واحدة، وتبقى النسخ المتعمدة من الرابط نفسه، ويُحترم إغلاق التبويب الموثق، ولا يعاد إرسال إجراء ذي أثر خارجي. في المقابل، قد تكون استعادة رابط بلا حالة نموذج غير محفوظ نتيجة مقبولة إذا كانت السياسة معلنة. راقب أيضًا الزمن حتى تصبح الواجهة قابلة للاستخدام واستهلاك الذاكرة وعدد النوافذ. لا تعتبر فتح جميع الروابط مؤشر نجاح وحيدًا؛ يمكن أن يكون ذلك فشلًا إذا خلق تبويبات مضاعفة أو أفسد حالة العمل.

فصل مشكلة الاستعادة عن مشكلة تسجيل الدخول

قد يعود التبويب إلى موقعه بينما تنتهي جلسة المصادقة على الخادم، وقد تبقى كوكيز الجلسة بينما تفشل الصفحة في تحميل بياناتها. هذه ليست بالضرورة أخطاء إزالة تكرار. اختبر كل بروفايل مستقلًا، وافصل حالة التخزين المحلي عن صلاحية التوكن وحالة الشبكة. لا تنقل كوكيز بروفايل إلى آخر بحجة إنجاح الاستعادة. إذا كان المتصفح يستخدم أقسام تخزين مؤقتة وأخرى على القرص، سجّل الفرق. واحذر افتراض أن Electron يطابق Chrome في كل سلوك إدارة النوافذ والتخزين دون اختبار النسخة الفعلية.

كيف تعرض الاستعادة للمستخدم دون مفاجآت؟

عند وجود تعارض، اعرض ملخصًا بسيطًا: عدد التبويبات المعروفة، وعدد التي أعيد استخدامها، وعدد الناقصة، وعدد التي تحتاج قرارًا. لا تعرض أسرارًا من عناوين URL أو بيانات نماذج حساسة في واجهة عامة. اسمح للمستخدم بإلغاء استعادة تبويب أو فتح جلسة سابقة في نافذة منفصلة إن كان ذلك آمنًا. احتفظ بخيار الرجوع إلى اللقطة السابقة مدة محدودة، ولا تحذف النسخة الوحيدة قبل التأكد من نجاح الاستعادة. التوقع الواضح أفضل من استعادة صامتة قد تغير حالة العمل.

أخطاء هندسية متكررة

من الأخطاء إنشاء كل تبويب من السجل دون قراءة النوافذ الحية، أو اعتبار URL مفتاحًا فريدًا، أو تشغيل عاملين من دون قفل، أو إعادة كل الخطوات بعد فشل تبويب واحد، أو إزالة تبويب مشروع لأنه يشبه آخر. كذلك لا تختبر بملف تعريف إنتاجي مليء ببيانات حساسة؛ اختبارات الإنهاء القسري قد تفسد تخزينًا محليًا. عالج كل خطأ بخطوة تحقق محددة وسجل قرار المصالحة. إذا تعذر إثبات هوية تبويب، علّمه uncertain بدل اختلاق تطابق وإغلاقه. راقب الأعطال المتتالية ولا تدخل حلقة إعادة تشغيل بلا حد.

المصادر والقراءة المرتبطة

لفهم الحدود العامة لاستعادة الجلسة راجع دليل إيجي تاج: https://egytag.com/ar/articles/اختبار-استعادة-التبويبات-بعد-crash-ما-الذي-يجب-قياسه-فعلا . هذا المقال يضيف تصميم مفاتيح الهوية والمصالحة ومنع الازدواجية، لا يكرر اختبار ظهور النوافذ. توضح وثائق Chrome Extensions واجهة tabs ومعلومات التبويب في https://developer.chrome.com/docs/extensions/reference/api/tabs ، وتشرح Electron إدارة BrowserWindow في https://www.electronjs.org/docs/latest/api/browser-window . تختلف الواجهات حسب الإصدار؛ راجع ما ينطبق على تطبيقك قبل اعتماد الخوارزمية.